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SECTION  1 
1.0  Introduction 

1.1  Purpooo 

The  purpose  of  this  technicsl  report  is  to  provide  a  discussion  of 
the  advsnced  capabilities  developed  and  the  Impact  these  capabilities 
■'eve  on  the  system  and  It  users. 

1.2  Scope 

This  documents  covers  the  following  aspects  of  CSP: 

o  a  descriptive  discussion  of  the  accomplishments  on  the 

advanced  capabilities  developed  and/or  analyzed. 

o  a  discussion  on  tha  development  of  system  support  task. 

Including  Installation  support,  configuration  management, 
software  quality  assurance  and  software  maintenance. 

1.3  Report  Organization 

The  CSP  technical  report  Is  orglnized  Into  four  sections.  Section 
one  serves  as  a  general  Introduction  to  the  CSP  system:  Its  development. 
Incorporation,  goals,  and  status.  Section  two  describes  the  CSP 
capabilities  end  acompllshments.  Section  three  Itself  consist  of  three 
parts.  Part  one  of  section  three  details  the  technical  performance  of 
the  CSP.  Included  In  this  discussion  ere  the  following:  Improved 
transportability;  site  unique  gateways;  operating  system  upgrade; 
hardware/sof tware  analysis;  online  retrieval  of  traffic;  Improved 
message  altroute  capability;  plain  language  addressing;  and  software 
Interface  to  AUTODIN.  The  second  part  of  section  three  describes  the 
CSP  system  support  functions.  They  Include:  CSP  Installation  support; 
configuration  management;  software  quality  assurance;  computer  programs; 
end  software  melntenance.  The  third  part  of  section  three  details 
on-site  maintenance  at  tha  seven  CSP  sites.  Finally,  section  four 
summarizes  all  conclusions  and  recommendations  for  the  CSP. 

1 .4  Background 

1.4.1  Initial  Development 

The  Air  Force  Intelligence  Service  (AFIS) .  Directorate  of 
Intelligence  Data  Management  CIND)  Is  manager  of  the  Air  Force 
Automatic  Data  Processing  System  (ADPS]  for  Intelligence  Deta  Handling 
Systems  (IDHS)  -  better  known  as  ADPS-90.  The  A0PS-90  manager  uses  the 
CUBIC  program  as  an  orderly  and  systematic  approach  for  developing, 
Implementing,  disseminating,  maintaining  and  supporting  certain  common 
software  for  use  by  Air  Force  and  other  qualified  agencies/activities 
that  use  AN/GYQ-211V)  minicomputers. 
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CUBIC,  the  Common  User's  Baseline  for  the  Intelligence  Community  Is 
a  centralized  management  program  for  software  design,  development, 
maintenance  and  control,  aimed  at  eliminating  redundant  software  efforts 
by  providing  a  set  of  standard  systems/subsystems.  CUBIC  has  al6o  come 
to  be  known  as  the  software  architecture  philosophy  used  In  managing 
these  software  systems.  The  CUBIC  philosophy  entails  active  u6er 
determination  of  functional  requirement  priorities,  centralized  software 
development  and  maintenance,  emphasis  on  modular  software  design  lending 
Itself  to  transportebi llty ,  and  software  design  that  can  be  adapted  to 
meet  site  specific  needs. 

The  CSP  was  developed  at  Headquarters  Strategic  Air  Command  (SAC)  as 
part  of  the  Operational  Intelligence  Support  System  (OISS).  In  June 
197B,  the  CSP  was  tested  under  the  provisions  of  DoD  Manual  5030.58  and 
accredl ted/certl fed  by  Defense  Intelligence  Agency  (DIA]/0ef ence 
Communications  Agency  (OCA)  as  a  DSSCS/GENSER  AUTODIN  automated  message 
processing  exchange  (AMPE).  The  CSP  has  been  operational  at  HQ  SAC 
since  September  197B. 

1.4.2  CUBIC  Incorporation 

AFIS/INO  as  the  USAF  A0PS-90  manager  was  aware  of  other 
Intelligence  user  requirements  to  automate  Special  Security  Offices 
(SSOs).  Therefore  In  late  1978  AFIS  adopted  CSP  as  a  CUBIC  entity. 
This  meant  that  CSP  could  be  supported  for  various  Air  Force 
requirements  and  dovetailed  with  the  HQ  SAC  effort  to  provide  a  single 
software  baseLlne.  CUBIC  CSP  was  installed/accredited  at  HQ  MAC  In  May 
1979  and  has  been  operational  since  June  1979.  Subsequently  CSP  hBS 
been  Installed  under  the  CIA3IC  program  at  PACOM  Data  Services  Center 
(PDSC),  Hawaii  and  at  the  U.S.  Army  Training  and  Doctrine  Command 
Facility  ITRADOC)  TCATA,  Ft.  Hood,  Texas. 

In  February  1980,  a  working  group  comprised  of  representatives  from 
DIA,  AFIS,  RADC,  SAC,  and  PDSC  recommended  to  the  Assistant  Secretary  of 
Defense  for  Command,  Control  Communications  and  Intelligence  (C3I)  that 
CSP  be  adopted  as  an  Interim  standard  for  Special  Security  Office  (SSO) 
Fixed  Base  Telecommunications  automated  message  handling  systems.  This 
recommendation,  which  was  subsequently  approved.  Included  eppointment  of 
AFIS/IND  as  executive  agent  for  life  cycle  mengement  of  CSP  software. 
In  November  1980,  the  Director  of  DIA  and  the  Air  Force  Assistant  Chief 
of  Staff/Intalllgence  signed  the  official  CSP  executive  agent  agreement. 

1.4.3  Contract  Boats 

The  contract  goals  ware  established  to  provide  the  following 
accomplishments  In  a  timely  menner: 

o  Improved  Transportability  -  This  task  Included  work  required 
to  facilitate  distribution,  configuration,  installation,  and 
subsequent  support  of  the  CSP. 
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o  Site  Unique  Gateways  -  This  Included  work  to  Improve  end 
etenderdlze  gateway  Interface  techniques  for  the  CSP  ae  well 
ae  research  and  develpment  of  new  gateways  ae  directed  by  RAOC 
and  AFIS/IND. 

o  Operating  System  Upgrade  -  This  Included  modifications  to  the 
CSP  oriented  to  the  Interface  to  end  use  of  the  operating 
8y  stem  (IAS] .  Also  Included  In  this  task  wee  work  required  to 
keep  the  CSP  operable  under  the  latest  release  of  IAS. 

o  Hardware/Software  Analysis  -  This  Included  an  analysis  of  the 
potential  evolution  of  the  CSP  bb  related  to  hardware  and 
software  options. 

o  Online  Retrieval  of  Traffic  -  This  task  equipped  the  CSP  with 
the  capability  to  retrieve  traffic  from  the  online  system 
message  file. 

o  Improved  Message  Alt-Route  Capability  -  This  provided 
enhancements  to  the  existing  CSP  software  which  allow 
alternate  routing  of  messages  between  selected  output  queues. 

o  Plain  Language  Addressing  -  This  task  allowed  for  Input 
message  traffic  to  the  CSP  either  In  the  format  specified  for 
DD  form  173.  Joint  Message  Form,  or  as  a  fully  formatted 
message  from  an  Intelligent  OCR  device. 

o  Software  Interface  to  AUTODIN  -  This  analysis  examined  the 

feasibility  and  work  required  to  develop  an  Interface  to  the 
AUTODIN  ASC  using  only  software. 

o  CSP  Installation  Support  -  This  Involved  four  phases  of  CSP 
Installation:  Site  survey,  base  software  configuration, 
software  Installation,  and  site-unique  baseline  definition. 

o  Configuration  Management  -  This  task  ensured  adherence  to  well 
defined  orocedures  for  Implementing  additions  or  modifications 
to  the  CSP  standard  system. 

o  Software  Quality  Assurance  -  This  task  resulted  In  the 

development  and  Implementation  of  a  Quality  Assurance  Plan. 
This  assured  compliance  with  ell  software  requirements  of  the 
contract. 

o  Computer  Programs  -  The  objective  of  this  Item  to  ensure  that 
the  most  current  version  of  all  CSP  software  was  delivered  to 
AFIS/IND  for  distribution. 

o  Software  Maintenance  -  This  task  included  work  which  provided 
centralized  maintenance  support  for  all  CUBIC  sites. 

o  On-site  Maintenance  -  This  task  provided  on-site  software 
maintenance  support  to  sites  requesting  this  level  of  CUBIC 
support. 
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1.4.4  System  Status 


The  CSP  has  been  In  operation  for  over  4  years.  Since  Its 
Initial  operational  date  In  September  1978,  the  system  has  compiled  an 
Impressive  record  of  accompllehments.  CSP  down-time  Is  recorded  In 
terms  of  minutes-per-week;  It  has  proven  Itself  to  be  highly  reliable 
In  terms  of  protecting  secure  traffic;  and  It  has  never  lost  a  message 
as  a  result  of  system  design  or  software  deficiencies. 

CSP  Release  I  as  Implemented  at  HQ  SAC  In  1978  was  derived  from  the 
OIA  SPINTCOMM  facility  software.  However,  functional,  security  and 
hardware  changes  required  a  60S  rewrite  of  the  original  system. 
Moreover,  the  current  architecture  bears  little  resemblance  to 
SPINTCOMM  design.  CSP  Release  II  es  Implemented  under  CUBIC  auspices 
may  almost  be  considered  third  generation,  since  many  changes  to 
Improve  modularity  and  transportability  have  been  made.  As  a  part  of 
the  CUBIC  program,  the  CSP  has  been  InsteLled  on  a  variety  of  different 
hardware  configurations;  and  as  a  resuLt,  has  become  a  modular  system, 
readily  configurable  for  Installation  Into  various  environments. 
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SECTION  2 

2.0  Communication  Support  Processor  System  Description 

2.1  Functional  Description 

The  Communications  Support  Processor  (CSP)  16  a  computer  system 
designed  to  automate  the  functions  of  a  Telecommunications  Center  (TCC) 
and  serve  as  a  communications  front-end  processor  for  analyst  computer 
systems.  It6  development,  distribution,  and  maintenance  Is  under  the 
auspices  of  AFIS/IND,  Bolling  Air  Force  Base,  Washington,  D.C.  CSP  Is 
an  element  of  the  Common  User's  Baseline  for  the  Intelligence  Community 
(CUBIC).  CUBIC  serves  as  a  single  source  for  computer  systems  designed 
to  automate  nearly  all  phases  of  Intelligence  data  handling  functions. 

2.2  Summary  of  Capabilities 

CSP  can  best  be  described  as  a  collection  of  application  and 
system  level  computer  programs,  designed  to  execute  as  a  coordinated 
system,  for  the  express  purposs  of  store  end  forward  operations  on 
record  copy  message  trrfflc.  While  there  are  many  ancillary  functions 
of  CSP,  Its  primary  task  consists  of  reception  of  message  traffic, 
validation  of  proper  formet,  and  determination  of  required  routing. 

In  and  of  Itself,  CSP  Is  merely  a  message  management  system. 
Stripped  of  all  ancillary  processing,  CSP  16  a  system  which  reliably 
moves  data  from  one  point  to  another.  It  is  this  ancillary  software, 
however,  that  defines  the  characteristics  of  the  data  being  moved,  and 
that  operations  are  performed  along  the  way. 

Some  of  the  basic  functions  and  capabilities  provided  by  CSP  are 
listed  below: 

o  Mode  I  AUTODIN  R/Y  Interface 

o  Mode  II  Interface  Support 

o  Variety  of  Interfaces  and  Protocols  Supported 
o  Input  and  Output  Security  Check 

o  Message  Format  Validation 

o  Message  Journalization  and  Audit  Trail 

o  Message  Review  and  Dissemination 

o  Routing  Line  Segregation 

o  Classification  Stamping  of  Hardcopy  Output 

o  Message  Edit/Generation 

o  Output  Message  Logging 
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o  Alternate  Message  Routing 


o  Online  Message  Retrieval 
o  Real-time  Status  Display 
o  DD  Form  173  support 

o  Fully  Automated  Routing  and  Dissemination 
2.3  Summary  of  Development  Accomplishments 

A  detailed  description  of  -the  work  performed  on  each  of  the  SOW 
items  is  presented  in  Section  3  of  thi6  technical  report.  This 
paragraph  serves  as  a  summary  of  these  developments. 

The  work  performed  under  improved  transportability  and  operating 
system  upgrade  have  both  served  to  make  the  system  more  modular  and  more 
easily  configurable.  The  two  major  common  areas  in  CSP  were  made  table 
driven  and  a  third  was  restructured  into  a  dynamic  region  to  allow 
dynamic  system  reconfiguration.  The  system  has  been  converted  to  object 
module  distribution  and  the  implementation  of  the  dynamic  system 
generation  software  will  allow  the  CSP  to  be  distributed  in  task  image 
format. 

Several  new  gateways  were  analyzed  for  incorporation  into  the  CSP. 
This  led  to  a  refining  of  the  gateway  interface  techniques  to 
standardize  new  gateway  implementations. 

New  capabilities  were  added  to  the  system  in  the  form  of  online 
message  retrieval  by  several  parameters,  a  full  plain  language 
addressing  capability  with  DD  Form  173  input  from  several  sources,  and 
the  development  of  a  Command  Language  Interpreter  with  an  operator  help 
facility  to  simplify  operator  input. 

In  addition  to  these  developments,  several  analysis  tasks  were 
performed  which  looked  at  the  feasibility  of  development  of  a  Direct 
AUTODIN  Interface  in  software  to  replace  the  TLC,  and  the  feasibility  of 
migrating  to  different  hardware.  Including  eliminating  the  BR1569  or 
BR1731  multiplexer.  Another  analysis  focused  on  upgrading  CSP  to  run 
under  RSX  11M  or  RSX  11M+  as  opposed  to  IAS,  as  well  as  the  capability 
to  utilize  more  of  the  IAS  3.1  features. 
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SECTION  3 


3.0  Technical  Performance 

3.1  Advanced  Capabilities  Development 

This  category  includes  all  SOW  Items  which  Involve  analysis  or 
developments  which  are  technical  In  nature.  The  result  of  each  Item  wa6 
either  the  development  of  the  actuaL  capability  or  the  publication  of  a 
technical  report  outlining  what  steps  would  be  necessary  to  develop  the 
capabl 11 ty . 

3.1.1  Improved  Transportability 

This  task  Involved  work  to  facilitate  the  distribution, 
configuration.  Installation  and  subsequent  support  of  the  CSP  system. 

3.1 .1.1  Objective 

The  objective  of  thl6  task  was  to  provide  AFIS/IND  with  a 
baseline  CSP  system  which  Is  very  welL  defined  and  can  be  easily 
distributed,  configured,  and  Installed  at  user  sites;  and  which 
requires  no  programmer  Intervention  to  do  so. 

Three  specific  work  Items  were  Identified  to  accomplish  this 
objective.  The  first  was  conversion  to  a  table  driven  architecture, 
allowing  CSP  to  operate  Independently  of  those  data  structures  which 
define  Its  configuration.  The  second  Item  dealt  with  developing 
software  modules  necessary  to  perform  system  configuration  without 
programmer  Intervention.  The  last  Item  Involved  distribution  of  the  CSP 
software  In  task  Image,  rather  than  source  code. 

3.1 .1.2  Accomplishments 

The  work  performed  to  satisfy  the  objective  of  this  task  Is 
discussed  In  separate  paragraphs  below.  Each  paragraph  relates  to  one 
of  the  work  Items  discussed  above. 

3.1.1.2.1  Conversion  to  Table  Driven  Architecture 

The  two  major  system  common  aress,  CSPCOM  and  QUECOM,  were 
reorganized  and  consolidated  to  provide  a  single  data  structure  dealing 
with  system  configuration  and  control.  A  programmers'  reference  manual 
was  published  to  enable  software  developers  to  Interface  the  new  data 
structure.  The  CSP  security  common  srea  was  restructured  Into  a 
dynamic  memory  region  to  permit  dynamic  configuration  of  this  area. 

3.1 .1.2.2  SY88EN  Configuration 

Software  and  an  Indirect  command  file  were  developed  to 
allow  the  system  manager  to  Initially  configure  the  CSP  with  respect  to 
output  queue  definitions,  communication  lines  definition,  and  system 
variable  definitions  within  the  data  structure  resulting  from  the 
consolidation  of  CSPCOM  and  QUECOM.  The  Indirect  command  file  allows 


the  system  mensger  to  create  a  date  file  for  a  full  system 
configuration,  perform  full  configuration,  perform  online  modification 
of  communications  lines  operating  parameters,  and  obtain  a 
configuration  summary. 

A  software  module  and  an  Indirect  command  file  were  developed  to 
allow  the  system  manager  to  define  the  contents  of  the  CSP  security 
table. 

The  indirect  command  files  were  developed  to  permit  definition  of 
configuration  parameters  in  terms  familiar  to  the  system  manager  rather 
than  a  software  developer.  Explanatory  comments  can  be  requested  to 
assist  the  manager  in  defining  the  system  parameters  and  security 
information.  Instructions  In  the  use  of  these  command  files  were 
published. 


3.1 .1.2.3  Task  Image  Distribution 

This  item  was  partially  accomplished  by  configuring  the  CSP 
for  abject  module  distribution.  All  subsequent  releases  of  Release  2.2 
change  2  will  be  made  In  object  module  form  only.  A  step-by-step 
flowchart  for  CSP  installation,  configuration,  and  acceptance  testing 
was  developed.  However,  these  steps  are  only  a  milestone  on  the  path 
to  task  Image  distribution.  Implementation  of  the  new  CSP  data 
structures  and  the  configuration  software  will  permit  CSP  distribution 
in  task  image  format.  These  capabilities  are  being  Incorporated  In  the 
release  3  baseline  under  development. 

3.1 .1.3  Discussion 

A  great  deal  has  been  accomplished  towards  satisfying  the 
objective  of  this  task.  The  conversion  to  table  driven  architecture 
and  development  of  software  for  performing  system  configuration  and 
security  table  definition  has  brought  CSP  closer  to  the  ultimate  goal 
of  task  Image  distribution.  Implementation  of  these  capabilities  will 
permit  the  CSP  to  be  installed  by  executing  command  fllee  to  roll  In 
software  from  a  release  tape  and  perform  system  configuration.  This 
method  of  Installation  Is  similar  to  that  of  an  operating  system 
Installation.  The  need  for  programmer  Intervention  In  the  Installation 
process  will  be  eliminated.  This  will  In  turn  free  up  contractor 
personnel  for  user  training  and  system  familiarization;  as  well  as 
reducing  the  cost  of  Installing  the  CSP  system. 
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3.1.2  Sits  Unique  Gateways 


This  task  Includes  work  required  to  Improve  and  standardize  the 
gateway  Interface  techniques  for  CSP,  as  well  as  research  and 
development  of  new  gateways,  as  dl  rected  by  RADC  and  AFIS/IND. 

3.1 .2.1  Objective 

There  were  three  basic  objectives  to  this  task.  The  first 
consisted  of  refining  gateway  Interfacing  techniques  so  as  to 
facilitate  new  gateway  Implementation  In  a  straight  forward  fashion. 
The  advantages  are  clear:  gateways  could  be  designed,  coded  and 
Implemented,  totally  Independent  of  the  baseline  CSP  from  the 
standpoint  of  system  modifications.  The  second  goal  was  to  build  a 
"library"  of  gateways  having  various  characteristics  which  could  be 
used  In  new  applications  as  either  direct  Implementations  or  as 
providing  a  starting  point  for  a  new  capability  gateway  which  Is  not 
currently  available.  The  third  goal  was  to  establish  procedures  and 
policies  by  which  AFIS/IND  could  provide  assistance  to  various 
organizations  desiring  to  Implement  non-baseline  or  site-unique 
gateways.  Such  assistance  would  take  the  form  of  technical  Input  and 
evaluation  or  outright  assistance  In  programming  efforts.  Each  goal 
has  been  met  and  specific  discussion  pertaining  to  accomplishments 
follows. 


3.1 .2.2  Accomplishments 

3.1 .2.2.1  6ateway  Interface  Modification 

A  substantial  amount  of  work  was  performed  In  the  area  of 
refining  gateway  Interface  techniques.  Perhaps  the  most  significant 
accomplishment  was  to  essentially  complete  the  conversion  of  CSP  to 
table  driven  architecture  In  the  area  of  communications  line 
Identification  and  control.  Prior  to  this  work,  a  great  deal  of  line 
characteristic  Informstlon  had  to  be  coded  Into  a  gateway  thus  making 
It  more  complex  and  unique  to  that  specific  Installation.  While  this 
did  not  adversely  affect  configuration  of  "standard"  lines  (such  as  the 
AUTODIN  Interface)  wherein  the  parameters  did  not  change  from  site  to 
site.  It  definitely  restricted  flexibility  and  ease  of  Installation 
where  a  particular  Bite's  requirements  wars  slightly  different  from 
those  for  which  the  gateway  was  written.  Having  to  make  modifications 
for  new  sites  necessitated  full  accreditation  and  presented  a  new  set 
of  variables  for  each  site. 

All  line  characteristics  are  now  contained  In  a  central  table 
(CSP COM)  and  need  only  be  set  up  during  Installation.  In  conjunction 
with  this  change,  gateways  were  modified  to  taka  advantage  of  these 
table  parameters.  The  nat  result  haa  bean  that  the  actual  number  of 
"baseline"  gateways  haa  bean  reduced  and  those  that  remain  are  simpler 
and  mors  universal. 
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Another  Modification  Made  was  to  recognize  the  actual  gateway  to  CSP 
core  Interface  Mechanism.  These  routines  (collectively  referred  to  as 
the  Message  Control  Subsystem,  MCS)  have  been  expanded  In  functionality 
and  the  access  Mechanism  (MACRO  calls)  have  been  reduced  In  number  end 
dramatically  simplified.  The  new  macro  calls  are  closely  patterned 
after  the  DEC  standard  file  system  calLs  (Files-11)  such  that  any 
programmer  reasonably  familiar  with  Files-11  can  easily  understand  end 
adapt  the  MCS  calls. 

This  new  software  has  not  been  Incorporated  Into  a  released  system 
as  yet  because  to  do  so  would  require  recoding  of  all  existing  gateways 
which  Is  not  cost  effective.  It  Is  scheduled  to  be  Included  In  the  next 
mqjor  release  of  CSP  as  an  alternate  set  of  routines  to  the  existing 
MCS.  Old  gatewsys  will  continue  to  use  the  current  MCS.  Newly 
developed  gateways  will  use  the  revised  version  and  thus  Incorporation 
can  be  phased  as  necessary.  All  new  gatewsys  end  any  existing  gateways 
requiring  modification  will  use  the  new  MCS  routines. 

3.1 .2.2.2  New  Gateway  Evaluation 

The  work  performed  under  this  Item  consisted  mainly  of 
technical  assistance  provided  to  AFIS/IND  and  CUBIC  (and  non-CUBIC) 
users  for  the  purpose  of  coordinating  and  evaluating  new  gateway 
Installation.  An  early  effort  was  the  establishment  of  an  Interface 
control  group  which  was  tasked  with  development  of  an  ICO  for  a  general 
purpose  high  level  protocol  gateway  for  CSP.  Preliminary  work  wa6 
performed  but  never  completed  unfortunately,  due  to  higher  priority 
tasking  by  AFIS/INO. 

Assistance  was  rendered  to  developers  of  the  OASIS  Installation  of 
CSP  (non-CUBIC)  for  their  CSP-MAXI  gateway  utilizing  the  PCL11 
hardware.  Assistance  and  guidance  was  also  given  to  TCATA  for 
development  of  a  CSP-CSP  Interface  utilizing  the  DV11.  Near  the  end  of 
the  contract  period,  assistance  wes  provided  to  SAC  for  development  of 
a  transmit  only  DDCMP  gateway  utilizing  DMC11  hardware. 

3.1 .2.3  Discussion 

For  the  most  pert  the  accomplishments  of  this  task  were 
consistent  with  the  Initial  goals.  A  foundation  has  been  laid  for 
subsequent  new  gateway  development  and  experience  has  been  gained  In 
building  new  gateways  and/or  assisting  others  In  doing  the  same. 

The  modifications  to  CSP  have  returned  significant  benefits.  PDSC 
was  able  to  design,  code,  and  Implement  the  Fully  Automatic  Routing 
Module  (FARM)  with  very  little  modifications  to  CSP  Itself.  In  fact, 
the  changes  required  to  Integrate  FARM  were  global  In  nature  and  allowed 
Integration  of  the  Plain  Language  Addressing  capability  (PLA)  with  no 
changes  whatsoever,  FARM  and  PLA  are  not  gateways  of  course,  but  they 
were  Interfaced  In  exactly  the  same  Manner.  Additionally,  the  gateways 
actually  written  were  Interfaced  with  no  CSP  Modifications  but  rather 
Made  using  table  entries. 
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This  has  resulted  In  another  benefit.  Work  Involving  systen 
configuration  was  wads  slwpler  and  wore  automatic  because  It  Is  now 
assy  to  pre-deflne  table  entries  for  all  Interfaces  and  thus  allow 
configuration  by  questlon/anawer  sequences  Including  those  Interface 
table  entries  specified  by  the  Installer. 
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3.1.3  Operating  System  Upgrade 

3.1 .3.1  Objective 

The  objective  of  this  tesk  wee  to  Include  eodlflcetlons  to 
the  C8P  primarily  oriented  to  the  Interface  to,  and  use  of,  the 
operating  system  (IAS).  As  with  most  operating  systems,  new  releases 
end  enhancements  are  a  continuing  effort,*  IAS  Is  no  exception.  This 
topic  covers  work  needed  to  keep  the  CSP  operable  under  the  latest 
releases  of  IAS.  This  work  Is  of  an  ongoing  nature. 

Four  specific  areas  have  been  identified,  relative  to  CSP 
improvements  designed  to  take  specific  advantage  of  IAS  enhancements. 

3 .1 .3 .2  Ac comp 11 shmsnts 

3.1 .3.2.1  Expanded  Use  of  Indirect  NCR 

The  use  of  Indirect  command  files  were  Implemented  for  such 
processes  as:  rolling-ln  distribution  tapes,  installation  and 

configuration,  all  aspects  of  the  "build"  process  including  single  disk 
sites,  all  phases  of  system  operation.  ALso  Included  In  this  Is  the 
capability  to  build  system  security  tables  and  system  common  areas. 
The  advantages  are  clear  through  the  use  of  Indirect  command  files, 
there  Is  little  room  for  error.  Repetitive  type  sequences  may  be 
executed  faster  and  more  reliably  by  Inexperienced  personnel,  thus 
making  the  system  easier  to  use. 

The  overall  result  of  this  work  Is  that  ell  CSP  processes  will  be 
performed  by  question/answer  sequences,  thus  eliminating  the  need  for 
programmer  Intervention  during  these  operations. 

3.1 .3.2.2  Development  of  a  Command  Language  Interpreter 

The  development  of  a  Command  Language  Interpreter  (CLI)  was 
successfully  completed.  The  CLI  was  written  specifically  for  the 
requirements  of  CSP  thereby  only  recognizing  CSP  commands.  This  in 
affect  will  enforce  the  security  of  both  CSP  and  IAS  by  means  of  only 
allowing  commands  that  are  permissible  to  CSP. 

The  CLI  wee  written  as  e  "user  friendly”  task.  This  Is  to  say  it 
will  be  easily  operated  by  SSO  personnel,  due  to  the  fact  that  a 
prompting  sequence  will  ask  for  the  need  Information  in  order  to  carry 
out  a  specific  command.  However  if  the  entire  command  is  completed  at 
any  given  point  no  prompting  will  appear.  This  command  structure  will 
be  easily  learned  due  to  this  logic  and  simplicity,  therefore  training 
of  new  personnel  will  be  less  a  problem  than  It  currently  Is. 

The  CLI  was  written  as  a  complete  table  driven  routine  using  the 
IAS  Table-Driven  Paraer  (TPARS),  designed  to  parse  commend  lines. 
TPAR8  provides  the  means  to  define  a  unique  syntax  and,  using 
TPAR8-suppl1ed  macros,  built-in  variables,  and  coding  provided  by  the 
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contractor,  recognize  a  command  line  written  In  that  ayntax.  With  the 
above  Implementations,  maintenance  and  future  CSP  expansion*  of 
coaaands  are  straightforward. 

3.1 .3.2.3  DaveLopaant  of  an  Operator  "HELP"  Facility 

This  task  was  Intended  as  a  coaprehanal va  "HELP"  facility 
for  CSP.  It  was  designed  to  work  directly  with  the  CLI  for  CSP.  The 
help  coaaand  displays  Inforaatlon  at  the  terminal  to  assist  the 
operator  In  Issuing  further  coaaands.  Inforaatlon  la  provided  at  three 
different  levels:  1)  A  help  coaaand  without  paraaetera  causes  the 
naaes  of  all  the  available  CSP  coaaands  to  be  Listed.  2)  A  particular 
coaaand  name  followed  by  the  key  word  "HLP"  causes  the  names  of 
qualifiers  and  paraaetars  to  the  coaaand  to  be  listed.  3)  A 
particular  command  name  followed  by  the  key  words  "HLP  EX"  causes 
examples  of  the  complete  command  line  to  be  listed. 

The  operator  may,  at  any  point  and  time,  type  In  the  key  word  "HLP" 
or  "HLP  EX”  and  a  full  explanation  or  an  example  of  the  coaaand  In 
progress  will  be  presented,  followed  by  the  repeated  prompt. 

This  feature,  coupled  with  the  Improved  coaaand  structure,  does  a 
great  deal  to  promote  user  acceptance  and  significantly  reduce  the 
amount  of  time  needed  far  operators  to  gain  proficiency  In  CSP  use. 

3.1 .3.2.4  Future  IAS  Utilization 

The  operating  system  was  upgraded  from  version  3.0  to 
version  3.1  and  the  CSP  mss  upgraded  to  run  under  this  executive.  A 
technical  report  was  provided,  presenting  the  features  of  IAS  and  the 
Impact  of  Implementing  RSX-11H+. 

The  potential  features  of  the  IAS  operating  system  were  Identified 
and  utilized  to  Increase  the  efficiency  of  the  CSP  system,  decrease  Its 
resource  requirements  and  Improve  upon  Its  functionality.  The 
development  of  the  Coamand  Language  Interpreter,  devalopaant  of  the 
operator  "HELP"  facility,  and  the  usage  of  Indirect  coaaand  files  are 
all  taking  advantage  of  the  operating  system  capabilities. 

3.1.3  Discussion 

The  result  of  this  effort  Is  an  overall  Improvement  of  the  CSP 
In  the  areas  of  performance,  maintenance  and  use,  by  taking  advantage 
of  the  operating  system  capabilities. 
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3.1.4  Hardwara/Software  Analysis 

3.1 .4.1  ObJ active 

Analyze  the  various  evolution  paths  for  CSP  as  related  to 
hardware  and  software  options.  Provide  the  Information  necessary  to 
evaluate  the  merits  of  the  various  hardware  and  software  alternatives. 

3.1 .4.2  Accomplishments 

Handlers  were  written  to  evaluate  the  0V11  and  DUP11  as 
alternative  OJ-389  Interfaces.  These  handlers  ere  the  functional 
replacement  for  the  BR1569  for  OJ-389  support.  The  DUP11  handler  Is 
currently  operational  and  In  use  et  the  Bellevue  facility. 

3.1 .4.2.1  Hardware  Analysis 

Alternate  communication  devices  were  evaluated  for  possible 
use  In  a  CSP  system.  The  analysis  Included  consideration  of  the  DV11 , 
DUP11,  DP11 ,  DZ11,  DHI-i,  DL11,  COMM  IOP-DZ,  COMM  IOP-DUP.  DQ11,  DMC11 
and  the  KMC11-A  as  communication  Interfaces  to  be  supported  by  CSP. 
The  basis  of  much  of  thl6  analysis  was  to  determine  whether  or  not  the 
current  CSP  communication  support  could  be  provided  by  using  DEC 
communication  Interfaces  rather  than  those  of  another  vendor. 
Evaluation  has  shown  that  DEC  communications  Interfaces  could  be  used 
for  all  of  the  current  and  foreseeable  CSP  Interfaces. 

Another  area  that  was  researched  wbb  the  possibility  of  the 
Implementation  of  a  gateway  to  replace  the  TLC  hardware  In  favor  of  a 
DEC  Interface.  The  evaluations  performed  here  have  Indicated  that  this 
Is  very  feasable,  and  could  be  accomplished  using  a  DV11,  DQ11,  or  even 
0UP11  as  the  supporting  Interface.  The  TLC  could  thus  be  totally 
eliminated. 

Alternatives  were  studied  for  OJ-389  replacements  using  more 
conventional  (and  less  expensive)  terminals.  The  analyels  has 
Indicated  that  various  approaches  are  viable,  ranging  from  the  'dumb' 
terminal  to  the  DEC  Professional  System  desktop  computers.  All 
alternatives  offer  the  advantages  of  being  more  cost  effective  and 
requiring  less  unique  hardware. 

CSP  host  systems  wsrs  evaluated  from  the  point  of  view  of  both  the 
Implementation  of  a  'mini  CSP'  and  the  expansion  of  capabilities  of  the 
'maxi  CSP'  systems.  CSP  was  Implemented  on  the  11/24  at  the  Bellevue 
elte.  Other  hardware  alternatives  for  a  CSP  host  that  were  evaluated 
ranged  from  the  Micro  T-11  based  systems  (primarily  In  a  distributed 
processing  envlrnment)  to  the  VAX  systems  (In  conjunction  with  the 
Implementation  of  a  suitable  HOL).  Results  have  Indicated  that  any  POP 
11  family  system  with  UNI8US  architecture  could  currently  be  used  to 
host  the  CSP.  The  Implementation  of  CSP  In  a  HOL  would  open  the  range 
of  possibilities  beyond  the  POP  11  family. 
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3.1 .4.2.2  Software  Analysis 

A  detailed  analysis  of  RSX  11M  and  RSX  11H+  was  performed  to 
determine  their  suitability  for  support  of  the  CSP.  RSX  11M  was  found 
to  be  lacking  In  several  key  areas,  but  RSX  IIMf  proved  to  be  very 
suitable  for  CSP;  In  fact  offers  many  Implementation  alternatives  not 
currently  available  under  IAS. 

UNIVAC  STEP-4  terminal  software  was  evaluated  and  determined  to  be 
useful  as  a  first  step  towards  the  development  of  a  hardware 
Independent  terminal  support  subsystem. 

Areas  of  software  efficiency  were  addressed,  and  In  many  Instances 
changes  were  Implemented  to  Improve  the  Bystem  performance.  In  most 
cases  this  Involved  the  restructuring  of  moduLes  to  eliminate  redundant 
coding  and  Inter-task  communications. 

An  analysis  of  HOLs  was  performed,  and  several  languages  Including 
ADA,  C,  and  FORTH  were  found  to  be  capable  of  being  used  In  an 
efficient  manner  to  Implement  CSP. 

3.1 .4.3  Discussion 

Hardware  Is  currently  available  to  allow  the  Implementation  of 
CSP  using  DEC  communication  Interfaces  only.  Thl6  Is  advantageous  from 
both  an  economic  point  of  view,  and  a  logistics  point  of  view.  A  range 
of  host  systems  is  available  In  the  POP  11  faml  Ly  that  allows  the  use 
of  the  newer  processors  (11/24,  11/34,  and  11/44)  to  more  closely  match 
the  requirements  of  small  Installations.  Alternate  approaches  to  the 
terminal  support  subsystem  suggest  the  utilization  of  standard 
terminals  rather  that  the  OJ-389;  this  Is  faasable  and  could  lower  the 
cost  of  a  small  CSP  system  considerably. 

IAS  Is  going  to  be  supported  through  1985.  It  Is  currently  a  very 
stable  operating  system.  8ut,  If  vendor  support  for  new  peripherals  Is 
to  be  available,  an  upgrade  to  a  supported  operating  system  would 
eventually  have  to  be  made.  If  the  conversion  of  CSP  to  a  HOL  was 
deemed  to  be  desirable,  serious  consideration  should  be  given  to  the 
Idea  of  remaining  with  IAS  while  the  software  la  written  In  assembler, 
and  upgrading  to  another  operating  system  (possibly  VMS  on  .a  VAX 
system)  In  conjunction  with  the  HOL  conversion.  This  would  eliminate  a 
great  amount  of  effort  necessary  for  the  assembly  language  CSP 
conversion,  which  Is  not  an  Immediate  requirement.  It  would  also 
result  In  the  Implementation  of  CSP  In  a  HOL  In  a  much  more  timely 
fashion. 
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3.1.5  Online  Retrieval  of  Traffic 

This  task  Involved  work  performed  to  provide  a  message  recall 
capability  form  the  online  message  file  disk. 

3 .1 .5 .1  ObJ ectl ve 

The  objective  of  this  task  was  to  develop  software  to  allow 
the  system  operator  to  recover  traffic  from  the  current  message  file 
dl6kf  based  on  a  set  of  retrieval  parameters,  and  reintroduce  It  to  the 
6y6tem;  thus  making  It  available  for  retransmission  and/or  editing  on 
the  0J-3S9  terminal.  This  capability  was  to  Include  recovery  of 
traffic  without  use  of  the  history  tape  provided  the  traffic  Is  still 
present  on  the  message  file  disk. 

3 .1 .5 .2  Accomp 11 shments 

Work  performed  by  the  Informatics  team  consisted  of 
Integrating  the  SAC  CSP  message  recall  software  Into  the  CUBIC  CSP 
baseline  following  Its  Implementation  at  SAC  and  updating  all  CUBIC 
documentation  to  reflect  Its  Incorporation. 

3 .1 .5 .3  D1 8CU88 1 on 

The  Informatics  team  considered  severaL  methods  of 
Implementing  this  capability.  After  consideration  of  the  requirements 
of  thl6  capability.  It  was  decided  to  await  completion  of  the  online 
message  recall  software  under  development  at  SAC,  under  a  separate 
contract.  The  software  being  developed  addressed  all  requirements 
defined  for  this  capability.  The  Informatics  team  participated  In  the 
design  review  and  software  validation  processes  at  SAC.  Following 
government  acceptance  of  the  online  retrieval  software,  the  Informatics 
team  Incorporated  the  software  Into  the  CSP  CUBIC  baseline  and  updated 
the  appropriate  CSP  documentation.  The  method  of  Implementation  chosen 
yielded  significant  benefits,  most  notably  acquisition  of  this 
capability  In  a  very  cost-efficient  and  timely  manner. 

This  capability  has  reduced  the  amount  of  time  required  to  effect 
message  retrieval.  It  allows  recovery  by  a  Large  set  of  parameters, 
ensuring  that  recall  can  be  performed  using  communications  center 
parameters,  such  as  CDSN  and  OSRI/SSN,  as  well  as  user-supplied 
parameters,  such  as  date-time-group.  This  capability  has  almost 
eliminated  the  need  to  perform  message  retrieval  from  history  tapes, 
freeing  operating  personnel  and  the  offline  CSP  system  for  other  uses. 
Additionally,  implementation  of  this  capability  has  laid  the  groundwork 
for  evolution  of  the  CSP  to  a  system  which  does  not  require  magnetic 
tape  archival  storage. 
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3.1 .6  Improved  Massage  Alt- routs  Capability 

3.1 .6.1  Objective 

This  task  provides  enhancements  to  the  existing  CSP  software 
which  allows  alternate  routing  of  messages  between  selected  output 
queues.  Improvements  will  allow  Individual  nessage  alternate  routing 
based  on  Message  OSRI,  precedence,  classification,  routing  Indicator  or 
assigned  office  symbol  dissemination. 

3 .1 .6 .2  Accoap 11 shaents 

Work  wee  performed  on  this  Item  under  a  separate  contract  at 
SAC.  CUBIC  tasking  was  to  Incorporate  the  completed  software  Into  the 
CUBIC/CSP  baseline.  Due  to  the  delays  encountered  at  SAC  In 
Implementing  this  software,  the  CUBIC  Integration  could  not  be 
completed  during  this  contract  period. 

3.1 .6.3  Discussion 

The  Improved  message  alt-route  capability  Is  now  essentially 
completed  at  SAC,  however,  the  final  step  of  system  checkout,  test  and 
Integration  Is  stllL  to  be  completed.  As  soon  as  this  phase  Is 
completed,  the  entire  capability  will  be  Incorporated  Into  the  CSP 
baseline  and  made  available  to  all  CSP  users. 


3.1.7  Plain  Language  Addra88lng 

3.1 .7.1  Objective 


Completion  of  this  ta6k  resulted  in  installation  of  software 
allowing  input  message  traffic  to  the  CSP  either  In  the  format 
specified  for  00  Form  173,  Joint  Message  Form,  or  86  a  fully  formatted 
message  from  an  "intelligent"  OCR  device. 

3.1 .7.2  Accomplishments 

3.1 .7.2.1  Analysis 

An  extensive  Plain  Language  Addressing  (PLA)  analysis  phase 
was  performed  which  resulted  In  the  preparation  and  publication  of  CDRL 
A012,  PLA  Analysis  Report.  This  report  examined  two  possible 
approaches  which  could  be  taken  to  provide  a  PLA  capability  to  the  CSP. 
Option  one  called  for  development  of  a  smart  OCR  gateway  which  would 
accept  input  from  an  OCR  after  it  fulLy  formatted  the  DD  Form  173  into 
the  proper  narrative  format.  This  option  would  be  relatively  simple  as 
it  would  only  require  a  new  gateway  to  a  new  type  of  device  and  would 
not  require  any  changes  to  the  core  of  the  CSP.  The  second  alternative 
called  for  development  of  the  actual  PLA  software  with  the  CSP,  as  well 
as  an  input  gateway  for  a  dumb  OCR.  This  option  would  require 
extensive  modifications  to  the  CSP  to  accept  a  new  format  of  message 
and  perform  all  conversion  and  routing  indicator  assignments.  The 
analysis  report  concluded  with  a  recommendation  to  pursue  option  two 
and  develop  the  PLA  capability  within  the  CSP  Itself.  After 
publication  of  this  report,  the  recommendation  was  adopted  and  the  PLA 
development  began  on  the  CSP. 

3.1 .7.2.2  Development 

The  development  phase  of  the  PLA  effort  was  begun  by 
publishing  a  Subsystem  Design  Specification  which  outlines  the 
functions,  requirements,  interfaces,  and  design  details  of  each  of  the 
PLA  modules.  The  PLA  subsystem  consists  of  four  basic  segments:  the 
Optical  Character  Reader  Gateway  (OCRCON),  the  PLA  Statistics  Task 
(PLSTAT),  the  PLA  Data  Base  Update  Task  (PLAUPD),  and  the  main  PLA 
Message  Expansion  (PLACON).  PLACON  Is  further  divided  into  overlays 
consisting  of  a  header  validation  segment,  a  message  format  line 
building  segment,  and  a  PLA  to  routing  indicator  conversion  segment. 
The  PLA  data  bases  are  structured  as  Indexed  seqnentlEl  files  created 
and  maintained  by  RMS-11.  This  is  a  very  powerful  data  base 
maintenance  feature  of  the  DEC  IAS  operating  system. 

The  functions  and  capabilities  of  the  PLA  subsystem  Include 
validation  of  all  DD  Form  173  header  fields,  determination  of  DSSCS  or 
GENSER  community,  conversion  of  all  PLAs  to  routing  Indicators, 
processing  of  address  indicator  groups  (AIGs)  and  DSSCS  address  groups 
(DAGs),  exempting  PLAs  from  AIGs  and  DAGs  and  prohibiting  the 
transmission  of  the  message  to  local  addressees.  If  the  message  Is 


DSSCS,  a  check  will  be  mede  to  ensure  the  TCC  of  the  message  is  allowed 
to  b8  transmitted  to  each  of  the  addressees.  For  GENSER  messages,  a 
proper  transmission  release  code  is  assigned  to  any  message  containing 
foreign  PLAs.  The  entire  message  is  converted  to  the  proper  AUTODIN 
format,  either  001-103  or  JANAP-128,  sectioned  and  paginated  if 
necessary  and  reintroduced  into  the  CSP  as  a  new  message.  As  such,  it 
is  subjected  to  the  full  format  check  and  finally  sent  to  the 
supervisors  review  queue  for  release  authorization  prior  to  actual 
transmission  to  AUTODIN. 

3.1 .7.3  Discussion 

The  PLA  capability  was  designed  as  a  modular  subsystem  and  may 
be  implemented  or  omitted  at  8ny  particular  Location.  The  memory 
requirements  of  PLA  are  such  that  it  is  not  recommended  to  be 
implemented  on  a  POP  11/45  or  any  other  CPU  with  only  128K  memory.  The 
disk  requirements  will  vary  widely  from  site  to  site  depending  on  the 
size  of  the  data  base,  however,  on  a  normal  message  fiLe  disk,  there  is 
usually  sufficient  space  available  for  this  purpose. 

The  basic  premise  guiding  the  development  of  PLA  was  that  the 
software  would  convert  a  DD  Form  173  formatted  message  to  the  proper 
format,  independent  of  the  source  of  the  DD  173.  Therefore,  it  is  not 
necessary  to  obtain  an  OCR  scanner  to  benefit  from  the  expansion 
capabilities  of  PLA.  it  is  only  necessary  to  supply  the  message  in 
exact  DD  Form  173  format  from  any  source  such  as  directly  from  the 
OJ-389,  or  from  a  backside  processor.  In  fact,  the  basic  PLA  software 
has  been  accredited  for  use  in  a  DSSCS/GENSER  environment  with  the 
primary  input  source  of  the  OJ-389  and  with  no  OCR. 


3.1.8  Software  Interface  to  AUTODIN 


3.1 .8.1  Objective 

The  current  interface  between  the  CSP  and  AUTODIN  consists  of 
a  combination  of  hardware  and  software.  The  objective  of  this  anaLyBis 
was  to  present  an  analysis  of  possible  interfaces  that  may  be  U6ed  as 
alternatives  to  the  current  interface  between  the  CSP  and  AUTODIN.  The 
primary  objective  of  these  alternate  interfaces  was  to  provide  a  direct 
interface  to  AUTODIN  as  opposed  to  the  current  interface  which  utilizes 
a  pre-processor  interface  (TLC). 

3.1 .8.2  Accomplishments 

A  study  was  performed  to  carefully  analyze  the  functions  of 
the  TLC,  and  the  AUTODIN  interface  protocoL.  The  hardware  interface 
consists  of  a  8B-1569  Multiplexer  located  in  the  AN/GYQ-211V)  system 
and  an  Analytics  Teleprocessing  Line  Controller  [TLC).  The  software 
interface  is  a  non-pri vi leged  task,  calLed  the  AUTODIN  gateway  [or 
TLCCON],  that  manages  the  transmission  and  reception  of  messages  via 
muLtiple  AUTODIN  circuits.  Each  AUTODIN  line  is  interfaced  to  a  TLC 
through  the  BFM569  Multiplexer  to  the  host  AN/GYQ-21  [ V) .  The  results 
of  the  analysis  showed  that  an  interface  to  AUTODIN  could  be  designed 
utilizing  only  standard  DEC  communications  devices  [eliminating  the 
TLC).  This  anaLysis  resulted  in  a  technical  report  on  the 
accomplishment  of  that  task. 

3.1 .8.3  Discussion 

The  'software  TLC'  i6  both  feasable  and  desirabLe.  The 
current  TLCCON  gateway  should  be  updated  to  support  the  AUTODIN  MODE  I 
protocoL  in  accordance  with  DCA  circular  370-D195-3,  and  a  handler 
developed  for  a  suitable  DEC  communications  device  to  support  the  link. 


3-14 


3.2  Systea  Support 


Thi6  category  of  work  efforts  involved  work  that  was  performed 
which  is  more  service  oriented  than  product  oriented.  The  previous 
category  dealt  with  actual  software  development  and  analysis  tasks 
resulting  in  the  publication  of  technical  reports,  whereas  this  section 
deals  with  Intangibles.  Items  to  be  covered  here  consist  of  CSP 
installation,  configuration  management,  quality  assurance,  computer 
programs  and  software  maintenance  activities. 

3.2.1  CSP  Installation  Suppport 

3.2.1 .1  Objectives 

Work  performed  for  this  task  involved  all  aspects  of  CSP 
installation.  Installation  of  the  CSP  consists  of  four  well  defined 
steps,  each  of  which  must  be  carefully  and  properly  executed  if  the 
goal  of  successful  installation  and  user  acceptance  is  to  be  achieved. 

3 .2 .1 .2  Acconp l i shments 

3.2.1 .2.1  Site  Surveys 

A  thorough  site  survey  was  the  key  to  a  successful  CSP 
installation.  This  site  survey  was  performed  by  Informatics  personnel 
several  months  prior  to  the  actual  installation  of  the  hardware  or 
software.  It  was  designed  to  accomplish  two  major  objectives,  to 
gather  information  and  to  provide  information.  Information  needs  to  be 
gathered  on  all  the  site  parameters  such  as  routing  indicators,  office 
symbols,  and  security  levels  of  the  TCC  and  all  the  lines.  Also,  e 
complete  hardware  list  needs  to  be  obtained  end  the  users  requirements 
must  be  stated  at  this  time.  All  this  information  was  used  to  properly 
configure  the  CSP  for  installation  at  this  particular  site.  The  second 
phase  consisted  of  providing  Information  to  the  site  managers 
concerning  the  capabilities  end  functions  of  CSP  Bnd  matching  these  to 
their  requirements.  Assistance  was  provided  to  the  site  managers  In 
selecting  the  proper  hardware  and  software  to  meet  their  needs. 
Schedules,  milestones,  security  aspects  end  operator  preparedness  was 
also  discussed  at  this  time. 

During  this  period  the  following  site  surveys  were  performed: 
LANTCOM,  Norfolk,  Virginia 
FTD,  Wright  Patterson  AFB,  Ohio 
USAFE,  Ramstein  AFB,  Germany 
-  ACCOM,  Colorado  Springs,  Colorado 
REDCOM,  MacDill  AFB,  Florida 


EUCOM,  Stuttgart,  Germany 
-  USAREUR,  Heidelberg,  Germany 

FSTC.  Charlottesville,  Virginia 

3.2.1 .2.2  Base  Software  Configuration 

Once  the  6ite  survey  was  completed  and  all  the  necessary 
information  was  gathered,  the  CSP  was  configured  for  the  site  prior  to 
the  actual  installation  at  the  user  site.  This  consisted  of  defining 
the  lines  to  be  used  at  the  site  in  CSPCOM,  defining  the  output  queues 
in  the  macro  QUEUES,  and  defining  for  each  queue  the  legal  altroutes  in 
the  macro  QUEOFF.  Other  parameters  were  also  preconfigured  if  the 
total  multiplexer  channel  assignment  was  known  in  advance.  Base 
software  configuration  activities  were  conducted  prior  to  installation 
of  the  CSP  at  LANTCOM,  FTD,  USAFE,  ADCOH,  and  REDCOM. 

3.2.1 .2.3  Installation 

Installation  of  the  CSP  is  a  two  person  effort  with  one 
person  actually  building  the  system  and  configuring  all  the  site  unique 
parameters,  while  the  second  person  assists  the  user  in  preparation  of 
all  user  maintainable  tables,  such  as  routing,  dissemination,  user  ID, 
and  security  tables.  These  are  functions  which  the  user  must  be  able 
to  perform  and  it  is  critical  that  this  function  be  successful.  Once 
the  system  is  Installed,  training  of  user  personnel  began  immediately 
by  one  person,  while  the  other  person  began  a  thorough  system  test  In 
accordance  with  the  CSP  Installation,  Test,  and  Site  Acceptance  Plan. 
Ouring  this  cor  tract  period,  CSP  was  installed  at  LANTCOM,  FTD,  USAFE, 
A DCOM,  and  REDCOM. 

3.2.1 .2.4  Site  Unique  Baseline 

After  a  successful  installation  of  CSP  at  each  site,  the 
system  installation  personnel  gathered  sufficient  information  about  the 
configuration  of  the  CSP  that  was  just  Installed  to  enable  the 
establishment  of  a  site  software  and  hardware  Inventory.  This 
consisted  of  listing  the  moduleB  containing  all  line  and  queue 
definitions  and  queue  altroutes  as  well  as  the  system  generation 
command  files  which  define  the  hardware  configuration.  Al6o.  any 
software  changes  made  at  the  site  were  noted  end  that  software  was 
transported  back  to  Bellevue  end  incorporated  into  the  CSP  baseline 
where  appropriate.  Checksums  were  run  against  all  software  Installed 
at  the  site,  and  these  checksums  were  compered  against  a  listing  of  CSP 
baseline  checksums  maintained  In  Bellevue.  All  this  Information  was 
released  to  the  configuration  manager  for  incorporation  into  the 
Informatics  Configuration  Management  System  data  bsse. 
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3.2.2  Configuration  Management 

3.2. 2.1  Objectives 

Configuration  management  is  the  application  of  systematic, 
technical  and  administrative  procedures  to  Identify  and  document  the 
functional  and  physical  characteristics  of  the  CSP  baseline  modules  as 
well  as  the  site  tailored  software  et  each  Installation.  Configuration 
management  ensured  adherence  to  well  defined  procedures  for 
implementing  additions  or  modifications  to  the  CSP  standard  system  and 
provided  a  mechanism  for  recording  and  reporting  change  processing  end 
implementation  status. 

3. 2.2.2  Accomplishments 

3.2.2.2.1  Software  Inventory 

An  accurate  record  of  CSP  software  was  maintained  during 
this  contract  period  with  the  aid  of  an  automated  Configuration 
Management  System  (CMS)  developed  at  Informatics.  With  the  use  of  this 
in-house  tool,  all  CSP  baseline  software  was  Identified  and  recorded. 

3.2.2.2.2  Software  Modifications  Control 

As  CSP  software  updates  were  incorporated  into  the  CSP, 
either  as  modifications  to  baseline  or  site-unique,  they  were  logged 
into  the  CMS  using  a  unique  coding  system.  Using  this  coding  system,  it 
was  possible  not  only  to  track  the  updated  versions  per  baseline  but  to 
identify  and  record  ths  site  unique  software  modifications  as  well. 

3.2. 2. 2. 3  Software  Modification  Distribution 

As  new  or  updated  CSP  modules  were  released  and  distributed, 
the  configuration  management  system  played  an  essential  part  in 
maintaining  records  of  the  releases.  Using  a  site  subsystem  In  the 
automated  system,  a  record  of  the  most  current  CSP  release  per  site, 
was  maintained. 

3.2.2.2.4  Site  Configuration  Support 

The  CMS  supported  each  site  configuration  by  maintaining  e 
site  inventory.  This  Included  for  each  site  the  current  CSP  release, 
the  date  of  Installation  and  any  site  unique  software. 

3.2.2.3  Discussion 

Informatics  has  developed,  as  an  in-house  tool,  an  automated 
configuration  management  system  to  aid  In  the  Identification  and 
maintalnance  of  all  CSP  software.  This  tool  has  been  a  valuable  asset 
by  providing  an  accurate  record  of  changes  within  the  CSP  for  the  past 
two  years.  It  reflects  the  software  Inventory,  software  modifications, 
problem  logging,  CSP  documentation  and  site  inventory  and  has  proved  to 
be  en  Instrumental  aid  In  ensuring  the  Integrity  of  the  CSP. 
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3.2.3  Software  Quality  A88urance 

3.2. 3.1  Objactlva 

The  Software  Quality  Assurance  task  wa6  Implemented  to  monitor 
and  control  the  quality  of  the  software  being  developed,  assure  that 
software  delivered  under  this  contract  complied  with  the  requirements 
of  this  contract,  and  to  guarantee  that  the  CSP  software  was  developed, 
tested  and  maintained  In  an  effective  and  efficient  manner. 

3.2 .3.2  Accomplishments 

Early  in  the  contract  period  the  Software  Quality  Assurance 
Program  was  established.  Procedures  were  established  for  work  tasking 
and  authorization,  testing,  corrective  action,  library  controls, 
documentation  preparation,  software  reviews,  end  software  development 
techniques  and  methodologies.  Throughout  the  contract  period  the 
enforcement  of  these  standards  has  contributed  immeasurably  to  the 
development  of  consistently  high  quaLity,  and  thouroughly  tested  CSP 
software. 


3. 2. 3. 2.1  Plan  Preparation 

The  Software  Quality  Assurance  Plan  was  prepared  according 
to  the  guidelines  provided  In  MIL-STO-1521 ,  Technical  Review  and  Audits 
and  DOD  Standard  7S35.1-S,  000  Automated  Data  Systems  Documentation 
Standards.  Particular  attention  was  given  to  a  practical 
implementation  of  a  plan  that  could  be  implemented  in  a  manner  that 
would  assure  that  the  software  would  be  of  the  highest  possible 
quality. 


3.2 .3 .2 .2  SQA  Activities 

Although  the  SQA  philosophy  is  constantly  present,  it  was 
particularly  evident  In  the  implementation  of  a  new  CSP  baseline.  This 
often  Involved  major  changes  to  the  software  to  Incorporate  new 
features  and  enhancements.  Thorough  testing  and  certification  was 
promoted  by  the  SQA  Implementation  guidelines  (CSP  Software  Quality 
Assurance  Program  TR-80-2550-04,  May  1981).  Baseline  testing  and 
verification  procedures  followed  the  guidelines  established  in  the  CSP 
Installation,  Test  and  Site  Acceptance  Plan,  which  describes  In  detail 
the  site  preparation,  system  generation,  site  operational  tables, 
training  and  security  accreditation.  The  Software  Quality  Assurance 
Program  activities  were  a  portion  of  every  phase  of  CSP  software 
development,  testing,  implementstlon,  training,  accreditation,  and  site 
acceptance. 
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3.2.4  Computer  Program 

3.2. 4.1  Objective 


All  computer  programs  assembled  or  developed  under  this 
contract  were  delivered  in  the  form  of  source  end  object  code  on 
magnetic  tape,  end  accompanied  by  source  listings.  Assembly  language 
wb6  used.  The  goal  of  this  task  was  to  ensure  thet  the  most  current 
version  of  ell  CSP  software  is  delivered  to  AFIS/IND  for  distribution 
within  the  prescribed  procedures. 

3. 2. 4.2  Accomplishments 

Since  AFIS/IND  does  not  currently  have  a  computer  facility  or 
the  capability  of  maintaining  the  baseline  and  distributing  the  CSP 
software  to  the  user  sites,  this  baseline  has  been  maintained  by 
Informatics  at  their  Bellevue,  Nebraska  development  facility.  As 
modifications  were  made  to  any  CSP  software  module,  they  were 
thoroughly  tested  before  incorporation  into  the  baseline.  Distribution 
was  made  to  the  user  sites  via  an  update  tape  containing  the  changes 
into  the  user's  system.  Initially,  all  changes  were  distributed  in 
source  form  and  the  system  had  to  be  reassembled  and  retaskbuilt  after 
each  change.  However,  the  system  migrated  to  the  point  where  it  could 
be  distributed  in  object  format  for  the  majority  of  the  modules.  Thus 
CSP  Is  now  installed  In  object  form  end  all  modifications  are  alBo  In 
object  module  form  where  appropriate.  The  only  source  code  supplied  to 
the  site  are  those  modules  that  ere  required  to  reconfigure  the  system 
tables  and  site  unique  parameters. 

3. 2. 4. 3  Discussion 

As  the  computer  facility  is  completed  at  AFIS/IND  the  CSP 
baseline  software  will  be  transferred  to  that  facility  and  maintained 
there.  This  will  consist  of  all  sources  and  object  modules.  From 
there,  object  module  distribution  will  be  made  as  it  Is  currently  done 
at  Bellevue.  Any  modifications  made  to  the  CSP  will  be  thoroughly 
tested  and  the  source  code  will  be  shipped  to  AFIS  to  update  the 
baseline. 
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3.2 .5  Software  Maintenance 


3.2. 5.1  Objective 

Software  maintenance  included  ell  work  providing  for 
centralized  maintenance  support  to  all  CUBIC  sites.  This  support  took 
the  form  of  CSP  problem  Identification  and  resolution,  as  well  as  CSP 
enhancements.  Problsms  were  identified  by  the  CSP  on-site  personnel 
and  resolved  by  project  personnel  at  the  Bellevue  development  facility. 

3.2. 5.2  Accompli ahmanta 

Over  the  two  year  period  of  the  CSP  contract,  several  major 
accomplishments  were  made  in  correcting  and  enhancing  the  CSP  contract. 
As  mentioned  above,  these  accomplishments  Included  problem  resolution, 
as  well  as  CSP  enhancements.  CSP  corrections  were  made  in  three  steps: 
problem  identification,  problem  resolution,  and  problem  response.  Each 
separate  process  was  activated  when  needed.  Each  area  is  discussed 
below.  Enhancements  included  suggestions  from  AFIS/IND,  as  well  as  the 
CSP  on-site  personnel.  General  maintenance  support  wa6  also  performed 
at  the  Bellevue  development  facility. 

3.2 .5 .2.1  Problem  Identification 

Problem  identification  was  an  important  aspect  of  software 
modification.  For  the  CUBIC  CSP  contract,  problem  identification  took 
two  forms:  full-time,  on-site  support  or  centralized  off-site  support 
from  the  Bellevue  development  facility. 

Generally,  problem  identification  began  with  recognition  of  a  CSP 
malfunction,  attributable  to  software,  by  operators  or  user  personnel 
at  e  CSP  installation.  AFIS/INO  was  Informed  of  this  malfunction  by 
the  Issuance  of  a  user  report  from  the  CSP  Bite  where  the  error 
occurred.  After  AFIS/IND  had  validated  the  problem  report,  Informatics 
was  notified  of  the  problem  and  began  to  diagnose  it.  Any  site 
specific  modifications  which  did  not  require  AFIS/IND  approval  were 
corrected  on-site  and  the  changes  communicated  to  the  Bellevue  office. 

3.2J5.2.2  Problem  Resolution 

Once  the  Bellevue  development  facility  received  the  problem 
report  from  AFIS,  the  process  of  problem  resolution  began.  If 
necessary,  phone  conversations  with  the  appropriate  on-site  personnel 
were  conducted.  In  order  to  clarify  the  nature  of  the  problem.  This 
was  followed  by  an  extensive  analysis  of  the  software  malfunction. 
Many  times  this  analysis  would  Indicate  that  an  actual  software  error 
had  not  occurred;  the  malfunction  could  be  traced  to  some  other  site 
occur ranee. 

If  the  problem  was  determined  to  be  a  software  error,  the  required 
corrective  action  was  determined  and  the  resulting  maintenance  tssk  was 
sized  and  scheduled.  AFIS/IND  was  then  given  necessary  Information  as 


3-20 


to  the  diagnosis  results  and  scheduled  corrections.  Under  the  terms  of 
the  contract,  this  notification  occurred  within  five  days  of  receipt  of 
the  probem  report. 

3.2.5.2.3  Problem  Response 

Once  AFIS/IND  had  been  informed  of  the  status  of  the 
software  error.  Informatics  kept  them  up  to  date  via  the  monthly  status 
report.  All  software  malfunctions  were  identified  as  either  'open'  or 
'closed' . 

Once  the  changes  were  made  and  successfully  tested  at  the  Bellevue 
facility,  distribution  was  made  to  the  appropriate  Installation. 
Depending  on  the  time  demands  on  the  problem,  distribution  was  made 
either  Immediately  or  at  a  convenient  time,  such  as  the  shipping  of  a 
site  release  tape. 

3.2.5. 4  6eneral  Maintenance  Support 

Along  with  problem  identification,  resolution,  and  response, 
general  maintenance  support  occured  at  the  BbIIbvub  development 
facility.  This  support  Included  implementation  of  new  CSP  releases; 
working  with  on-site  user  and  operator  personnel  to  investigate  CSP 
malfunctions;  and  analyzing,  planning,  designing,  coding,  testing, 
installing,  and  documenting  site  unique  software  modifications.  All 
these  software  modifications  were  designed,  developed,  tested,  and 
implemented  in  accordance  with  CSP  quality  assurance  and  configuration 
management  guidelines.  This  general  maintenance  support  served  as  an 
enhancement  to  CSP  functionality. 

3.2.5.3  Discussion 

For  the  most  part,  software  maintenance  functioned  during  the 
course  of  the  CUBIC  CSP  contract  as  described  above.  Ther?  was, 
however,  one  Important  change  in  software  maintenance.  In  January  of 
1982,  AFIS  published  guidelines  for  use  of  standard  Cubic  Problem 
Reports  (CPRs).  These  reports  provided  a  method  for  Identifying  all 
CSP  errors  on  a  numerical  system,  by  site,  as  well  as  in  sequential 
order.  In  addition  to  Identifying  CSP  software  errors  in  a  more 
efficient  fashion,  the  CPR  system  also  provided  for  accurate  record 
keeping  of  all  suggeetlons/enhancements  for  the  CSP.  These  suggestions 
and  enhancements  were  reviewed  by  AFIS  and  Informatics  end,  if  deemed 
appropriate,  were  acted  upon. 
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3.3  On-Site  Maintenance 


On-site  maintenance  of  the  baseline,  enhancements,  end  site  unique 
software  was  provided  as  a  site  option.  This  Included  analyzing, 
planning,  designing,  coding,  testing,  Installing,  end  documenting  site 
unique  software.  Also  Included  was  providing  f eml 11 arlzetl on  to 
selected  operators  and  programmer/enalysts;  Identifying,  analyzing, 
reporting  and/or  resolving  software  problems  or  enhancements ;  and 
providing  assistance  to  the  operating  agency  on  the  Integration, 
Installation  and  Implementation  of  new  CSP  he rdwa re/software.  Each 
6lte  currently  receiving  on-site  support  Is  d1scus6sd  below.  Appendix 
A  contains  additional  Information  on  each  site  at  which  CSP  Is 
Installed. 

3.3.1  TCATA,  Ft.  Hood,  Texas 

On-site  support  was  Initiated  during  the  month  of  June,  1981  at 
TCATA.  A  new  gateway  was  created  at  TCATA  which  utilizes  a  dynamic 
region  to  pass  messages  between  the  CSP  and  the  TCATA  Output  Message 
Controller  and  Timer  [TOMCAT].  An  Interface  was  also  developed  between 
the  CSP  and  the  Battlefield  Evaluation  and  Target  Acquisition  (BETA) 
system.  A  third  gateway  was  designed  to  aLlow  CSP-CSP  communications 
over  a  satellite  link  to  allow  for  the  deploymen!-  of  the  Remote 
Communications  Processor  (RCP).  This  gateway  operates  through  a  DEC 
DV11  multiplexer.  Several  joint  exercises  were  supported  by  CSP  and 
the  on-site  personnel  during  this  contract  period.  No  significant 
problems  were  encountered  with  CSP  support  during  any  of  the  exercises 
in  which  CSP  participated. 

3.3.2  MAC,  Scott  AFB,  Illinois 

On-site  support  was  initiated  during  the  month  of  June,  1981  at 
MAC  also.  MAC  is  operating  under  a  unique  hardware  configuration  with 
both  the  CSP  tasks  and  the  message  file  on  a  single  disk.  This  does 
not  require  any  special  software  to  support  this  arrangement,  however, 
the  on-site  support  representative  Is  needed  to  keep  the  system 
operational  under  this  configuration.  Any  time  the  system  pack  gets 
corrupted  due  to  hardware  failure,  It  is  necessary  to  cold  start  the 
system  since  the  message  file  is  coresident.  This  arrangement  has  not 
appeared  to  hamper  on-line  operations  except  for  the  frequent 
degradation  of  the  ability  to  recover  messages  on-line  from  the  message 
file  after  a  cold  start.  Recently,  several  problems  have  been 
encountered  causing  the  system  to  hang  up  and  occasionally  causing  a 
system  crash  with  a  memory  parity  error.  This  has  necessitated  the 
removal  of  CSP  release  2.2  change  2  and  the  fall-back  to  change  1. 
Change  2  will  be  reinstalled  when  the  system  is  moved  to  the  POP  11/45s 
recently  obtained  by  MAC  and  the  hardware  problems  can  be  eliminated. 

3.3.3  USAFE,  Ramsteln  AFB,  Germany 

On-site  support  was  begun  at  USAFE  during  the  month  of  August, 
1981.  A  modification  to  the  TLC  gateway  was  made  at  USAFE  which 
alternates  use  of  the  two  AUTODIN  communications  lines  to  allow  more 


3-22 


r 


equitable  U6e  of  the  dual-homed  capability  of  the  CSP.  This 
modification  wa6  Incorporated  Into  the  baseline  and  wa6  redistributed 
to  other  CSP  sites.  A  problem  wa6  identified  end  resolved  concerning 
the  BR1S69/TLC  Interface.  A  unique  problem  was  discovered  at  USAFE 
regarding  the  50HZ  power  supply  and  its  unstable  effect  on  the  system 
time.  They  were  experiencing  a  frequent  I066  of  time  from  the  system 
clock,  which  prompted  the  on-site  representative  to  modify  CSP  to  allow 
a  change  of  time  online.  Another  unique  problem  found  relates  to 
releasabl 11 ty  of  messages  to  non-US  personnel.  In  particular, 
TOPSECRET  messages  should  be  allowed  to  be  released  to  certain 
countries  based  on  the  routing  Indicator  and  SPECAT  designator.  The 
solution  Is  currently  being  analyzed  and  a  modification  will  be  made  to 
CSP  to  allow  release  of  these  messages. 

3.3.4  LANTCOM,  Norfolk,  Virginia 

On-site  support  was  Initiated  during  the  month  of  September, 
1981  at  LANTCOM.  The  unique  use  of  Teletype  Model  40  printers  86 
Baudot  messages  and  service  printer  devices  caused  a  new  printer 
handler  to  be  developed  to  handle  formfeeds  and  printer  timeout 
conditions.  Another  requirement  was  initiated  at  LANTCOM  which  called 
for  processing  multiple  action  addressees.  This  capability  was 
developed  for  LANTCOM,  but  has  become  pert  of  the  CSP  baseline 
capabilities.  A  problem  surfaced  at  LANTCOM  regarding  the  handLing  of 
CRITIC  messages,  specifically  the  rigid  format  validation  performed  by 
CSP  and  the  possible  rejection  of  the  message  due  to  format  errors. 
LANTCOM  proposed  to  bypass  format  validation  of  CRITIC  messages 
providing  that  format  lines  2  and  16  were  correct  and  could  therefore 
Identify  the  message  as  a  CRITIC,  The  change  was  made  by  site 
personnel  at  LANTCOM  without  coordinating  the  change  with  AFIS  or  the 
proper  office  in  DIA.  A  meeting  was  set  up  between  AFIS,  DIA,  LANTCOM, 
and  Informatics  personnel  and  a  proper  solution  was  agreed  upon  by  all 
parties,  The  solution  to  the  problem  16  being  designed  and  will  be 
implemented  In  a  standard  manner,  to  replace  the  fix  at  LANTCOM. 

3.3.5  ADCOM,  Colorado  Springs,  Colorado 

On-site  support  was  bsgun  at  ADCOM  during  the  month  of  January, 
1982.  The  actual  Installation  of  the  CSP,  however,  did  not  occur  until 
mid-August  1982,  due  to  facility  construction  delays.  After 
Installation  an  attempt  was  made  to  perform  system  accreditation 
testing,  which  felled  due  to  several  factors.  Including  Incomplete 
wiring,  wrong  signal  level  at  the  Western  Union  J-Box,  leek  of  support 
at  the  ASC,  and  untrained  operators.  These  problems  were  resolved  by 
mid-October  and  accreditation  retesting  occurred,  this  time 
successfully.  The  problems  remaining  at  ADCOM  are  In  the  redundant 
channel  configuration  of  the  BR1731  multiplexer  end  the  NSA  circuit 
configuration  through  the  BR1731. 
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3.3.6  REDCOM,  MacOlU  AFB,  Florida 


On-site  support  was  initiated  at  REDCOM  during  the  month  of 
April,  1982.  The  hardware  was  Installed  and  the  BR1731  was  only 
configured  with  a  capability  to  support  a  Model  40  receive  only 
printer.  Since  full  duplex  communications  were  required  to  support  the 
RQJTF  facility,  modifications  were  made  to  the  Mode  II  Input  gateway  to 
support  Input  of  messages  through  the  teletype  handler. 

3.3.7  SAC,  Offutt  AFB,  Nebraska 

On-site  support  was  initiatsd  at  SAC  under  this  contract  during 
the  month  of  April,  1982.  Actual  on-site  support  was  provided  at  SAC 
from  the  time  of  the  original  installation  in  1978,  however,  this 
support  was  provided  under  a  separate  contract  to  SAC.  In  April,  the 
separate  SAC  contract  was  terminated  and  SAC  became  a  formal  CUBIC/CSP 
user.  Because  of  Its  proximity  to  the  Informatics  development 
facility,  much  of  the  support  provided  to  SAC  consists  of  implementing 
new  software  and  running  a  thorough  test  and  evaluation  prior  to  actuaL 
incorporation  into  the  CSP  baseline.  In  this  manner,  SAC  has  been 
designated  the  lead  command  for  all  CSP  developments. 
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3.4  COflLs 


The  following  CSP  documents  were  successfully  completed  end 
delivered  during  the  contrect  period. 

3.4.1  CSP  Status  Report  (CDRL  A001) 

The  CSP  Contrect  Status  Report  was  issued  monthly  and  identified 
the  status  and  activities  for  all  tasks  in  progress  in  terms  of 
performance,  status,  and  work  planned  for  the  next  reporting  period. 
Additional  sections  were  included  that  identified  management  items  of 
concern,  a  management  level  work  summary,  all  CSP  contract  related 
travel,  end  changes  in  project  personnel. 

3.4.2  CSP  Overview  (CDRL  A002) 

The  CSP  Overview  provided  an  overview  of  system  objectives  and 
requirements  suitable  for  management  and  generaL  informational  purposes. 
It  was  prepared  in  accordance  with  Data  Item  Description  No. 
R&D-1 B8-RADC . 

3.4.3  Functional  Requirements  Manual  (CDRL  A003) 

The  Functional  Requirements  Manual  provided  a  description  of 
common  system  capabilities  which  were  used  to  describe  the  system  to 
potential  users,  to  preview  the  system  when  training  user  personnel,  to 
serve  as  a  reference  for  user  personnel,  and  to  provide  a  performance 
checklist  after  installation.  Because  this  document  was  used  by  staff 
who  did  not  necessarily  have  computer  system  experience,  it  was  written 
using  language  which  was  as  nontechnical  as  possible.  It  was  prepared 
in  accordance  with  Data  Item  Description  No.  R&D-1B9-RADC. 

3.4.4  System  Design  Specifications  (CDRL  A004) 

Thu  System  Design  Specification  provided  a  detailed  definition 
of  CSP  functions  and  interfaces  with  other  system  snd  subsystems.  It 
was  in  accordance  with  Data  Item  Description  No.  R&D-190-RADC. 

3.4.5  System  Operator's  Manual  (CDRL  A005) 

The  CSP  Operator's  Manual  contained  complete  detailed  information 
on  the  system  console,  MDC/SVC  terminal,  and  offline  and  support 
procedures  necessary  to  successfully  operate  the  eutometed  support 
system.  It  wes  oriented  towards  computer  operators  and  message 
distribution  personnel  who  were  responsible  for  the  efficient 
performance  of  the  CSP,  and  included  appendices  covering  system  err^r- 
messages,  distribution  terminal  error  messages,  snd  system  command?-. 
Additionally,  a  separate  appendix  was  prepared  for  each  site  which 
contained  a  configuration  summary  and  other  Information  unique  to  that 
site.  Each  site  received  the  general  Operators  Manual  along  with  the 
appropriate  site  configuration  appendix  generated  as  s  result  of  the 
installation  process  of  the  particular  system. 
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The  manual  was  prepared  in  accordance  with  Data  Item  Description  No. 
R&D-1 91-RADC. 

3.4.6  Program  Haintananca  Manual  (CRDL  A006) 

The  CSP  Maintenance  Manual  presented  detailed  program 
descriptions  for  all  CSP  modules  and  information  on  the  maintenance  of 
these  modules.  It  was  technical  in  nature  and  was  developed  for 
personnel  who  were  responsible  for  the  maintenance  of  computer  programs. 
This  document,  together  with  a  program  listing  containing  programmer 
comments,  assisted  the  maintenance  programmer  in  making  modifications  to 
the  existing  system  programs  as  requirements  changed. 

3.4.7  Configuration  Management  Plan  (CDRL  A007) 

The  CSP  Configuration  Management  Plan  (CMP)  specified  Drocedures 
for  the  achievement  of  the  CUBIC  CMP  configuration  management  goals  for 
the  subset  of  all  CSP  software  developed,  disseminated  and/or  maintained 
by  Informatics  General  Corporation  under  the  CUBIC  Management  Program. 

3.4.8  Test  and  Implementation  Plan  (CDRL  A008) 

The  T&I  Plan  provided  guidance  for  management  and  technical 
efforts  throughout  the  Installation,  test  and  training  period  for  each 
installation.  The  T&I  Plan  detailed  procedures  for  initial  software 
Installation  and  subsequent  releases.  It  also  established  a 
comprehensive  test  plan  so  that  users  and  security  personnel  couLd 
demonstrate  and  validate  the  operational  capabilities  of  the  CSP.  By 
defining  and  publishing  such  a  benchmark,  against  which  the  system  could 
be  made  to  perform,  the  process  of  DIA/DCA  certification  could  be  made 
simpler,  and  more  standardized  for  the  user,  while  at  the  same  time 
providing  DIA/DCA  with  a  well  defined  procedure  and  published,  expected 
results. 

A  second  major  aspect  of  the  T&I  Plan  was  a  detailed  checklist  for 
installation  and  user  orientation/training.  This  checklist  was  used  by 
the  Informatics  installation  team  to  ensure  that  all  phases  of  CSP 
installation  were  properly  and  effectively  performed.  In  it  were 
detailed  key  points  and  milestones  relative  to  installation  as  well  as 
specific  items  of  a  user  training  nature  which  must  be  covered  to  ensure 
proper  user  preparation. 

3.4.9  Test  Analysis  Report  (CDRL  A009) 

The  Test  Analysis  Report  was  produced  by  the  Informatics  team 
following  accreditation  testing  of  the  CSP  for  new  installations  or  new 
releases  of  CSP  software.  These  reports  consisted  of  a  synopsis  of  test 
activities  Including  a  description  of  any  problems  encountered. 
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3.4.10  Operating  System  Upgrade  Interim  Technical  Report  (CORL  AGIO) 


The  Operating  System  Upgrade  Interim  Technical  Report  contained 
results  of  an  analysis  of  potential  for  use  of  specified  IAS  features. 

3.4.11  Hardwara/Software  Alternatives  Interim  Technical  Report  (CDRL 
A011J 

Two  reports  were  produced  as  part  of  this  contract  deliverable. 
The  first  consisted  of  a  report  identifying  a  set  of  generic  hardware 
configurations  which  can  support  the  CSP  and  associated  system 
capabilities.  The  second  report  addressed  the  capability  to  make 
certain  software  modifications  related  to  a  scaled  down  hardware 
version  of  the  CSP. 

3.4.12  Plain  Language  Addressing  (PLA)  Interim  Technical  Report  (CORL 
AQ12) 

The  PLA  Interim  Technical  Report  consisted  of  the  results  of  en 
analysis  of  two  possible  approaches  which  may  be  taken  to  provide  a  CSP 
capability  for  PLA. 

3.4.13  Software  Interface  to  AUTODIN  Interim  Technclal  Report  (CDRL 
A013] 

The  Technical  Report  for  the  feasibility  of  a  direct  software 
interface  to  an  AUTODIN  Switching  Center  (ASC)  included  results  of  Bn 
analysis  effort  projecting  impacts  on  memory  utilization,  throughput, 
efficiency,  and  security  accreditation. 

3.4.14  Final  Technical  Report  (CDRL  A014) 

This  Final  Technical  Report  (FTR)  for  the  CSP  Support  contract 
summarizes  the  results  of  work  performed  during  the  contract  period. 
This  report  identifies  CSP  cepabilities  and  deliverable  products  that 
were  produced. 

3.4.15  Quality  Program  Plan  (CDRL  A015) 

This  document  identified  requirements  and  procedures  for  a 
Software  Quelity  Assurance  Program  that  were  implemented  for  the  CSP 
Support  Contract.  The  Quality  Program  Plan  was  produced  in  accordance 
with  MIL-S-52779  guidelines. 
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SECTION  4 


4.0  Summary  and  Recommendations 

Reviewing  the  accomplishments  of  this  pest  contract  reveals 
that  many  tangible  improvements  have  been  made  to  CSP  which  brings  more 
productivity  into  the  telecommunications  center.  Without  a  doubt,  FARM 
and  PLA  significantly  broaden  the  applicability  of  CSP  ana  have  gained 
6trong  user  attention  and  anticipation.  Prior  to  these  was  online 
message  recall  which  has  all  but  eliminated  the  need  for  magnetic  tape. 
Another  visible  improvement  has  been  the  modifications  designed  for 
flexibility  and  transportability.  The  CSP  software  can  be  installed, 
configured  and  made  test  ready  in  under  half  a  day  and  be  done  in  a 
fashion  which  provides  complete  audit  trail  and  configuration 
management  information. 

From  a  functionality  standpoint,  it  can  be  seen  from  the  above  that 
significant  improvements  have  been  made  to  the  CSP.  To  the 
aforementioned  list  could  be  added  numerous  other  improvements  of  a 
lesser  nature,  but  nonetheless  supporting  the  evolution  of  CSP  from  a 
relatively  primitive  communications  processor  to  an  automated  full 
function  communications  system. 

Throughout  this  evolution  the  design  and  implementation  process  has 
included  considerable  thought  toward  anticipation  of  future 
requirements.  For  example,  while  the  PLA  capability  was  not  scheduled 
for  completion  until  late  1982,  the  foundation  for  PLA,  in  terms  of  data 
structure  modifications  and  other  "hooks",  was  laid  as  far  back  as  1980. 
This  has  allowed  integration  with  virtually  no  impact  anticipated  on 
existing  installations  when  upgrading  to  PLA.  Release  2.3  of  CSP  will 
include,  of  course,  PLA,  FARM  and  many  other  enhancements,  but  it  will 
also  include  "hooks"  for  future  anticipated  expansion.  In  terms  of  SOW 
items  for  the  follow-on  contract,  several  changes  have  been  anticipated 
and  the  foundations  laid  for  upgrading  CSP  to  RSX-11M  or  M+ ,  running  CSP 
on  a  smaller  hardware  configuration,  elimination  of  the 
History/Intercept  tape  requirement,  message  recall  by  service  message 
request,  and  modifications  to  the  MDC  terminal  operations. 

CSP  has  been  evolving  along  other  lines  besides  functionality.  The 
original  CSP  for  SAC  was  fairly  restrictive  as  to  the  hardware 
configuration  it  required  for  operation.  For  instance,  usage  of  other 
than  DEC  TU10  tape  drives  for  history  and  Intercept  required  software 
changes.  Today  CSP  is  much  less  restrictive  as  to  hardware 
requirements.  With  consideration  given  to  performance  8nd  capacity 
requirements,  CSP  can  be  offered  as  a  system  able  to  run  on  the  entire 
family  of  PDP-11  processors  (except  for  11/23  and  11/24  because  of  IAS 
operating  system  constraints).  CSP  can  use  as  a  message  file  data  base 
any  disk  drive  supported  by  the  operating  system  and  the  same  holds  true 
for  mag-tape  devices.  Because  CSP  was  designed  for  device  independence, 
it  can  take  immediate  advantage  of  new  peripheral  offerings  as  soon  as 
they  become  available  with  operating  system  support. 
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With  the  advances  in  hardware/software  technology  projected  to 
proceed  at  their  current  phenomenal  rate,  it  will  not  be  long  before  the 
current  CSP  hardware/software  architecture  will  be  updated  with  respect 
to  evailable  technology. 

From  a  hardware  standpoint  the  industry  move  is,  end  always  has 
been,  to  more  processing  power  in  smaller  packeges.  Much  more  emphasis 
1 6  being  place  on  distributed  processing  techniques  in  an  effort  to 
expand  the  capabilities  of  these  smaller  processors,  es  well  as  limit 
the  reliance  on  a  single  processor  for  all  functions.  The  other  obvious 
use  of  distributed  processing  is  to  get  more  capabilities  to  more 
people. 

Software,  too,  is  undergoing  a  change  in  terms  of  how  people  view 
its  use.  With  the  current  evolution  of  higher  order  languages  (HOLs), 
the  frequency  of  machine  languege  (MACRO-11,  BAL,  etc.)  implementations 
of  computer  programs  will  drop  dramatically  as  more  powerful  and 
flexible  HOLs  become  available.  Machine  language  has  historically  been 
selected  for  use  becuase  of  its  efficiency  and  ability  to  manipulate 
the  hardware  and  small  units  of  data  (bits,  bytes,  etc).  It  was  also, 
in  many  cases,  the  only  language  available  on  minicomputers  in  the 
early  stages  of  development.  This  is  rapidly  changing,  however  and  the 
time  is  not  far  off  when  machine  language  will  be  a  v.ool  used  only  by 
the  hardware  designer  when  building  the  machine  itself.  Consider  the 
DEC  VAX  11/780  which  implements  sophisticated  data  structure 
manipulation  operations  in  its  instruction  set,  or  the  Commerical 
Instruction  Set  (CIS)  option  for  the  PDP-11/24  and  11/44.  Many 
microprocessors  are  commercially  available  which  offer  the  PASCAL, 
BASIC,  and  "C"  languages  implemented  in  firmware,  and  which  cannot 
easily  be  programmed  in  machine  language.  A  major  drawback  to  machine 
language  has  been  and,  by  definition,  will  continue  to  be,  cost.  While 
it  is  generally  efficient  in  its  operational  form,  the  cost  to  develop 
continues  to  escalate  as  labor  costs  rise.  Machine  language 
programmers  are  hard  to  find  and  good  ones  demand  high  salaries.  The 
efficiency  of  machine  language  is  directly  dependent  upon  programmer 
expertise  while  with  higher  order  languages  a  large  amount  of 
efficiency  can  be  "built  In"  to  the  compiler  end  the  Language  itself. 
Another  drawback  to  machine  language  is  dependency.  For  example, 
software  coded  in  PDP  MACRO-11  cannot  be  executed  on  anything  but  a 
PDP-11.  This  is  not  necessarily  true  of  HOLs.  A  program  written  In 
"C",  PASCAL,  or  ADA  will  run  on  a  variety  of  computers  supporting  that 
language. 

Where  does  this  all  fit  with  CSP?  One  can  begin  by  looking  at  the 
user.  Telecommunications  centers  serve  a  vital  but  relatively  minor 
role  In  the  process  of  Intelligence  information  gathering  and 
dissemination.  The  message  traffic  itself  Is  merely  data  until  it  gets 
into  the  hands  of  the  intended  recipient  where  its  true  value  comes 
Into  play.  Many  of  the  processes  taking  place  in  a  communications 
center  require  significant  manpower  allocation  but  represent  minor 
capabilities  for  computer  systems.  As  these  TCC  processes  are 
translated  into  software,  less  effort  need  be  expended  on  moving  data 
and  more  can  be  spent  on  using  It. 


Most  communication  centers  have  Limited  space  and  in  most  cases 
that  space  must  be  shared  between  people,  communications  equipment, 
administrative  offices  etc,  and  finding  room  for  two  PDP-11/70  systems 
can  be  a  problem.  It  is  therefore  incumbent  upon  system  designers  to 
provide  more  compact  and  efficient  systems  which  get  the  job  done  but 
do  not  have  the  impact  on  space  of  the  current  larger  systems.  Coupled 
with  smaller  size  and  increased  performance  is  a  constant  requirement 
to  reduce  costs,  both  in  hardware  procurement/operation  and  in  software 
development  and  maintenance. 

Cost  reduction  and  performance  improvement  can  be  accomplished 
through  use  of  newer,  smaller,  more  powerful  equipment  including 
distributed  processing  techniques  and  through  other  techniques  such  as 
software  preparation  in  a  suitable  higher  order  language  such  as  ADA. 
The  result  will  be  a  very  efficient  (in  cost,  space  and  performance) 
system  with  wide  flexibility  and  applicability. 

To  a  certain  extent  CSP  stands  at  a  crossroads  with  respect  to 
future  evolution.  In  its  current  state  CSP  is  a  solid,  well  defined 
system.  If  TCC  requirements  were  never  to  change  and  currently  used 
hardware  continued  to  be  available,  then  CSP  could  continue  to  be  a 
viable  system.  Neither  of  the  above  premises  are  true  however  and  some 
decisions  must  now  be  made  concerning  the  evolution  path  to  take.  No 
single  path  represents  a  clear-cut  decision.  On  one  hand  there  is 
strong  support  for  migration  of  CSP  to  smaller  hardware  which  would 
give  the  same  or  slightly  more  capability  than  the  current  system. 
This  makes  sense  from  the  standpoint  that  the  hardware  is  moving  in 
that  direction  and  TCC's  don't  usually  have  physical  space  to  spare. 
On  the  other  hand,  changing  TCC  requirements  such  as  consolidation  of 
DSSCS/GENSER  facilities  as  well  as  overall  expansion  of  communication 
requirements  tends  to  support  the  move  of  CSP  to  larger,  faster 
hardware.  In  its  current  form  and  using  current  21 (V)  hardware,  CSP  is 
throughput  limited  to  perhaps  6000-8000  messages/day.  This  is  adequate 
for  most  applications  but  clearly  inadequate  for  many  potential  users. 

It  is,  of  course,  a  well  known  fact  that  D0D  is  pursuing  a  solution 
to  the  current  AUTODIN/Tributery  problem,  and  this  is  the  Inter-Service 
AMPE,  CSP  is  the  interim  standard  AMPE  and  as  such  is  scheduled  to  be 
replaced  by  I/S  AMPE,  or  is  it?  Even  though  I/S  AMPE  would  automate 
TCC's  as  well  as  serve  as  switching  nodes  for  the  DIN  network,  does 
that  eliminate  the  requirement  for  message  processing  systems  connected 
to  I/S  AMPE?  Today  CSP  provides  70%  of  the  functionality  projected  for 
I/S  AMPE  and  rough  estimates  for  I/S  AMPE  operation  are  for  the  late 
1980'a;  CSP  will  have  to  provide  service  until  then. 

The  work  items  identified  in  the  follow-on  contract  represent  some 
real  direction  in  this  decision  making  process.  Conversion  of  CSP  to  a 
higher  order  language  is  an  absolute  necessity.  It  mu6t  be  pursued  with 
serious  dedication.  ADA  represents  the  clear-cut  choice  of  languages. 
Lack  of  approved  compilers  is  a  temporary  problem,  but  it  is  anticipated 
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that  very  shortly  the  computer  manufacturers  will  begin  to  meke 
available  ADA  compilers  along  with  the  necessary  development  environment 
tools.  The  problem  of  hardware  dependence  must  be  resolved.  Thi6  will 
in  fact  be  partially  aLleviated  by  conversion  to  a  HOL  but  more  work 
must  be  done  In  order  to  use  standard,  vendor  supplied  options  end  thus 
remove  the  reliance  on  unique  (expensive)  sole  source  equipment. 

For  CSP  the  past  two  years  of  work  saw  the  overall  organization  and 
stabilization  of  the  system  into  a  well  defined  product.  New  capebility 
was  added  in  a  methodical  and  weLl  planned  fashion.  With  respect  to 
functionality,  CSP  is  now  mature.  The  work  to  be  performed  over  the  next 
several  years  must  focus  on  evolution  towards  refinement  of  the 
technology  and  expansion  of  applicability  and  flexibility. 
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HQ  SAC,  Offutt  APB,  Nebraska 


Site  Location 

The  CSP  became  operational  at  HQ  Strategic  Air  Command  (SAC)  In 
September  1978.  The  CSP  was  developed  at  HQ  SAC  as  part  of  the 
Operational  Intel llgenca  Support  System  (OISS)  of  the  IDH  Improvements 
Project. 

SAC  hss  a  world-wide  mission  of  deterring  war  by  being  prepared  to 
conduct  strategic  operations  on  a  global  ba6ls  with  the  objective  of 
destroying  an  enemy's  will  or  capability  to  wage  war. 

CSP  provides  both  OSSCS  and  CENSER  communications  support  for 
transmission  and  reception  of  real-time  AUTODIN  messages  In  support  of 
SAC's  mission.  In  addition,  the  CSP  functions  as  a  front-end  processor 
for  the  Analyst  Support  Processor  (ASP),  which  directly  supports  SAC's 
Intelligence  analysts. 

Equipment  Configuration 

The  CSP  at  SAC  Is  currently  Implemented  on  the  following  hardware 
for  the  primary  system: 

o  CPU  -  One  (1)  PDP-11/70  with  256K  memory 

o  System  console  -  One  (1)  LA120  DECwriter 

o  Disk  drives  -  Three  (3)  BR1538D  (shared) 

One  (1)  RL01 

o  Tape  drives  -  Two  (2)  TE16 

Three  (3)  TU10  (shared) 

o  Multiplexer  -  One  (1)  36-channel  BR1569 

o  Line  printers  -  One  (1)  LP11WA  (shared) 

One  (1)  B600 

One  (1)  TT  Mod-40  ROP  (shared) 

o  AUTODIN  Interface  Oevlce  -  Two  (2)  TLC100  (shared) 

o  Message  Distribution  Console  -  Three  (3)  OJ-389  (shared) 

o  Other  Equipment  -  One  11)  VT52  terminal 

One  (1)  paper  tape  reeder/punch 
One  (1)  CR11  card  reader  (shared) 

The  backup  system  Is  configured  Identically  to  the  primary,  those 
Items  listed  as  "shared"  above  are  switchable  between  the  two 
processors.  Additionally,  Individual  circuits  terminating  in  the  BR1569 
multiplexer  are  swltchable  between  both  processors  by  means  of  BR1568 
switches. 
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Software  Configuration 

Figure  A-01  contains  a  site  report  extracted  from  Informatics' 
Configuration  Management  System.  This  report  reflects  the  current 
software  release  level  for  this  site,  the  date  of  software  installation 
and  Implementation,  and  a  status  of  pending  releases.  Also  Included 
are  any  site  unique  modules  developed  for  this  particular  6ite. 

Communications  Configuration 

The  CSP  is  dual-homed  to  Tinker  and  Gentile  ASCs  for  online 
tributary  operations,  both  DSSCS  and  GENSER.  Backside  tributaries  at 
SAC  includes  the  ASP,  Mode  II  send  and  receive  circuits,  and  a  SPCL 
processor  for  deLivery  to  SOLARS. 

A  connectivity  diagram  for  SAC  is  presented  in  Figure  A-02. 

Current  Operations  Statistics 

SAC's  average  traffic  volume  and  CIM  rate  are  as  follows: 

o  Messages  transmitted  -  1569  per  month 

o  Line  blocks  transmitted  -  112,086  per  month 

o  Messages  received  -  56,301  per  month 

o  Line  blocks  received  -  1,421,982  per  month 

o  CIM  Rate  -  .57% 

The  CSP  i s  able  to  maintain  approximately  37  days  of  online  storage. 
SAC  has  been  able  to  maintain  a  low  CIM  rate  due  to  the  extensive  format 
and  security  checks  performed  by  the  CSP. 

Approximately  75%  of  the  Incoming  messages  are  derivatively  routed 
to  the  ASP.  Another  5-7%  are  derivatively  routed  to  the  SPCL  system. 
Approximately  5%  of  the  incoming  messages  are  derivatively  routed  to  the 
SRC.  The  remainder  of  the  Incoming  messages  Is  routed  by  the  message 
distribution  clerk. 

The  station  reliability  for  SAC  including  both  hardware  end  software 
outages  Is  approximately  99.64%. 

Future  Operations 

There  are  plans  to  replace  the  Interface  to  the  SPCL  system  with  en 
Interface  to  the  SAC  SOLARS  system  via  the  Micro-Programmable  Controller 
(HPC).  When  this  Intsrface  Is  complete,  the  amount  of  messages 
derivatively  routed  to  SOLARS  Is  expected  to  Increase  by  approximately 
3%. 
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SITE:  SAC  (SA) 


RELEASE:  2.2C2 

STATUS:  OPERATIONAL  30- APR-82 
DATE  OF  INSTALLATION;  30-APR-82 
REMARKS:  NONE 


******************************************************************************** 


UNIQUE  MODULES: 

MODULES:  INTCON.MAC 
IDENT:  V2.2SA1 

DESCRIPTION : 

INTCON  WAS  CHANGED  TO  SUPPORT  THE  CHANGES  MADE  TO  '  INTGWY.MAC'  OF  THE 
SAME  LEVEL.  EFFECTIVELY  THE  ASCII  LINE  NAME  IS  CONVERTED  BACK  TO  ITS 
ASSOCIATED  LINE  ID  BEFORE  ENTERING  CSP.  THIS  CHANGE  WILL  ALLOW  THE 
OPERATOR  TO  ENTER  INTERCEPT  TAPE  INFORMATION  BETWEEN  CSP  RELEASES. 

MODULES:  INTGWY.MAC 
IDENT:  V2.2SA1 

DESCRIPTION : 

THE  "PADWRITE"  ROUTINE  OF  INTGWY.MAC  WAS  EXPANDED  TO  ALLOW  A  CONVERSION 
OF  THE  LINE-ID  TO  ITS  ASSOCIATED  ASCII  LINE  NAME  BEFORE  WRITING  THE  PAD 
TO  TAPE.  THIS  CHANGE  WILL  ALLOW  OPERATOR  TO  ENTER  THE  INTERCEPT  TAPE 
INFORMATION  BETWEEN  CSP  RELEASES. 


Figure  A-01  SAC  Configuration  Status 
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Figure 


Site  Personnel 


There  are  no  CUBIC/CSP  on-site  representatives  per  6e  et  SAC.  The 
close  proximity  of  the  Bellevue  facility  to  SAC  makes  it  possible  for 
the  personnel  at  the  contractor's  facility  to  as6i6t  in  system  trouble 
shooting.  This  effort  is  conducted  largely  by  Mr.  Bob  Mack, 
Informatics  and  Mr.  Barry  King,  PRC.  Me66rs.  Mack  and  King  work  closely 
with  the  communications  and  data  processing  staffs  of  SAC.  Their 
primary  point  of  contact  is  l6t  Aerospace  Communications  Group. 
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HQ  MAC,  Scott  AFB,  Illinois 


Sits  Location 

CSP  was  Installed  at  HQ  Military  Airlift  Command  (MAC)  In  June 
1979.  This  was  the  second  Installation  of  CSP  after  SAC  succesefully 
demonstrated  the  ability  of  the  CSP  to  the  military  Intelligence 
community. 

MAC  has  a  world-wide  mission  of  providing  airlift,  logistic,  supply 
and  transport  support  to  all  000  elements.  A  secondary  mission 
consists  of  supporting  Air  Force  Communications  Command,  Air  Rescue  and 
Recovery  Service  and  Air  Weather  Service  components. 

CSP  provides  both  OSSCS  and  GENSER  communications  support  for 
transmission  and  reception  of  real-time  AUTODIN  messages  In  support  of 
MAC's  mission.  In  addition,  the  CSP  functions  as  a  front-end  processor 
for  the  MAXI  system,  which  directly  supports  MAC's  Intelligence 
analysts. 

Equipment  Configuration 

The  CSP  et  MAC  is  currently  Implemented  on  the  following  hardware 
for  the  primary  Bystem: 

o  CPU  -  One  (1)  POP  11/70  with  128K  memory 

o  System  Console  -  One  (1)  LA36  DECwrlter 

o  Disk  Drives  -  One  (1)  BR1538D 

o  Tape  Drives  -  Three  (3)  TU16 

o  Multiplexer  -  One  (1)  36  channel  BR1569 

o  Line  Printers  -  Two  (2)  80  character  line  printers 

o  AUTODIN  Interface  Device  -  One  (1)  TLC100 

o  Message  Distribution  Console  -  Two  (2)  OJ-389 

o  Other  equipment  -  One  (1)  VT52  terminal 

One  (1)  Paper  tape  reeder/punch 

There  Is  currently  no  backup  processor  to  be  used  In  the  event  the 
POP  11/70  or  one  of  Its  peripherals  Is  down.  If  the  down-time  Is 
excessive,  a  POP  11/70  used  to  support  MAXI  can  be  recabled  to  run  CSP. 


Software  Configuration 


Figure  A-03  contains  a  site  report  extracted  from  Informatics 
Configuration  Management  System.  This  report  reflects  the  current 
software  release  level  for  this  site,  the  date  of  software  installation 
and  implementation  and  a  status  of  pending  releases.  Also  included  are 
any  site-unique  modules  developed  for  this  particular  site. 

Connuni cations  Configuration 

The  CSP  is  homed  to  ASC  Gentile  for  online  operations,  both  DSSCS 
and  GENSER.  The  onLy  backside  tributary  at  MAC  is  the  MAXI  system. 
There  are  no  other  local  tributaries  or  communications  lines  configured 
at  this  time. 

A  connectivity  diagram  for  MAC  is  presented  in  Figure  A-04. 

Current  Operations  Statistics 

MAC'S  average  traffic  volume  and  CIM  rate  are  as  follows: 
o  Messages  transmitted  -  1,225  per  month 
o  Messages  received  -  25,225  per  month 
o  CIM  rate  -  .33% 

The  traffic  volume  has  been  steadily  increasing  at  the  rate  of 
10-15%  per  year,  while  the  CIM  rate  has  been  declining  dramatically. 
This  decrease  in  CIMs  is  largely  due  to  the  increased  format  checking 
and  stricter  security  checks  placed  on  each  message  by  the  CSP. 

With  MAC's  current  message  volume  and  single  disk  configuration, 
the  online  message  storage  capacity  Is  approximately  37  days. 

Virtually  all  of  the  incoming  messages  ere  reviewed  end  routed  by 
the  MDC  operator.  However,  approximately  90%  of  these  messages  are 
routed  to  the  MAXI  system. 

The  station  reliability  rate  for  MAC  has  averaged  97.4%.  This 
reflects  total  system  reliability  and  Includes  both  hardware  end 
software  downtimes  as  well  as  PMIs. 

Future  Operations 

A  POP  11/45  has  been  procured  and  configured  with  123K  memory. 
This  will  be  used  as  an  alternate  CSP  processor  in  the  near  term.  This 
new  configuration  will  Include  a  second  BR1538D  disk  drive  to  allow  a 
standard  message  file  disk.  In  the  tong  term,  there  are  plans  to 
procure  a  POP  11/44  and  migrate  the  CSP  software  to  that  processor. 
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SITE:  MAC  (MA) 

RELEASE:  2.2C1 

STATUS:  OPERATIONAL  2B-0CT-B1 

DATE  OF  INSTALLATION:  28-0CT-81 

REMARKS:  CHANGE  2  UPGRADE  SCHEDULED  IN  JANUARY.  1983 

*****************************************  **********  **********  ******************* 

UNIQUE  MODULES: 

NONE 


Figure  A-03  MAC  Configuration  Status 
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Figure 


An  additional  change  anticipated  is  to  obtain  a  second  TLC100  and  a 
link  to  Tinker  ASC  and  become  dual-homed  to  provide  redundancy  and 
faster  service. 

Site  Personnel 

The  CUBIC/CSP  on-6ite  representative  at  MAC  i6  Mr.  Charles  Ramsey, 
Informati  cs. 

Mr.  Ramsey  has  been  instrumental  in  the  high  rate  of  success  that 
r'RP  has  achieved  at  MAC.  He  has  performed  problem  analysis  and 
r  '.solution  in  a  timely  manner  and  has  responded  around-the-clock  to 
online  system  problems.  He  has  also  successfully  converted  the  system 
to  run  on  the  PDP-11/45  on  a  test  basi6  in  preparation  for  operational 
implementation  on  that  processor. 

His  day-to-day  operations  require  him  to  interact  with  several 
intelligence  divisions  as  well  as  data  automation  and  communications 
center  personnel. 
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TCATA,  Fort  Hood,  Texas 


Site  Location 

CSP  was  first  Installed  In  November,  1979,  at  the  TRADOC  Combined 
Arms  Test  Activity  (TCATA),  Fort  Hood,  Texas  on  a  PDP-11/45.  During 
September-October,  1981,  the  CSP  software  wes  moved  to  the  home  station 
PDP-11/70.  In  early  November,  1981,  TCATA  was  re-eccredi ted  by  DCA, 
DIA  and  DA.  In  April,  1982  ,  TCATA  installed  CSP  in  the  Remote 
Communications  Package  (RCP),  which  wa6  designed  by  our  on-site 
consultant,  Russell  Goad,  prior  to  his  release  from  active  duty. 

TCATA's  CSP  primary  mission  is  to  provide  a  communications 
interface  with  user  units  during  J.C.S.,  REDCOM  and  other  units' 
exercises.  TCATA's  CSP  also  has  a  mission  in  testing  the  Joint 
Tactical  Fusion  Test  Bed  (JTFTB)  located  at  both  Fort  Hood  end  Hurlbert 
Field,  Florida. 

Equipment  Configuration 

The  local  CSP  at  TCATA  has  the  following  hardware  configuration: 
o  CPU  -  One  (1)  PDP-11/70  with  2MB  memory 
o  System  Console  -  One  (1)  LA36  DECwriter 
o  Disk  Drives  -  Two  (2)  BR1538D 

o  Tape  Drives  -  Two  (2)  Kennedy  dual  density  drives 

(equivalent  to  TE16s) 

o  Multiplexer  -  One  (1)  32  channel  BR1569 

o  Line  Printers  -  One  (1)  Houston  Instrument  electrostatic 

o  AUTODIN  Interface  Device  -  One  (1)  TLC100 

o  Message  Distribution  Console  -  One  (1)  OJ-389 

o  Other  equipment  -  One  (1)  VT100  terminal 

One  (1)  DV11  multiplexer 
One  (1)  Paper  tape  reader 

The  Remote  Communications  Package  (RCP)  CSP  is  configured  slightly 
differently: 

o  CPU  -  One  (1)  PDP-11/70  with  1  MB  memory 
o  System  Console  -  One  (1)  LA36  DECwriter 
o  Disk  Drives  -  Two  (2)  BR153BD 
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Tape  Drives  -  Two  (2)  Kennedy  duel  density  drives 
(equivalent  to  TE16s) 

o  Multiplexer  -  Two  12)  16  channel  BR15B9 

o  Line  Printers  -  One  (1)  LP11Y 

o  AUTODIN  Interface  Device  -  One  (1)  TLC100 

o  Message  Distribution  Console  -  One  (1)  OJ-389 

o  Other  Equipment  -  One  (1)  VT10G  terminal 

One  (1)  DV11  multiplexer 
One  (D  Paper  tape  reader 

Software  Configuration 

Figure  A-05  contains  a  site  report  extracted  from  Informatics 
Configuration  Management  System.  This  report  reflects  the  current 
software  release  level  for  this  site,  the  date  of  software  installation 
and  implementation  and  a  status  of  pending  releases.  Also  included  are 
any  site-unique  modules  developed  for  this  particular  site. 

Communications  Configuration 

The  connectivity  of  the  two  CSPs  at  TCATA  varies  depending  on  thB 
exercise  being  supported.  Generally,  however,  there  is  a  Link  to  one 
ASC  and  anywhere  from  one  to  eight  MOD-40  teletypes  configured  as  Mode 
II  devices.  Also,  if  the  exercise  dictates,  there  could  be  a  satellite 
CSP-to-CSP  link  activated  via  the  satellite  communications  gateway. 

The  backside  computer  interface  at  the  local  CSP  consists  of  a 
receive  link  from  the  PDP-11/70  configured  as  a  Tactical  Simulator 
(TACSIM)  Output  Message  Control  and  Timer  (TOMCAT).  During  exercises 
the  TACSIM  processor,  a  VAX  11/780,  generates  messages  through  the 
TOMCAT  which  releases  them  to  CSP  on  a  timed,  controlled  basis.  CSP 
then  forwards  them  to  their  destination. 

The  local  lines  consist  of  the  MOD-40  teletypes  mentioned  above 
which  can  be  operated  either  locally  or  remotely.  There  ere  no  other 
local  tributaries. 

A  connectivity  diagram  for  TCATA  is  presented  In  Figure  A-06. 

Current  Operations  Statistics 

Since  TCATA  Is  not  an  operational  site,  there  Is  not  a  constant 
traffic  Load.  However,  during  the  exercise  periods,  the  TCATA  CSP 
handles  approximately  1800  to  2000  messages  per  day.  If  this  volume 
were  sustained  for  an  extended  period  this  equates  to  54,000  to  60,000 
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SITE:  TCATA  (TC) 

RELEASE:  2.2C2 

STATUS :  EXPERIMENTAL  30-APR-82 

DATE  OF  INSTALLATION :  30-APR-82 

REMARKS:  NONE 

*************************************** ***************************************** 
UNIQUE  MODULES: 

NONE 


Figure  A-05  TCATA  Configuration  Status 


messages  per  month,  or  almost  double  the  average  volume  for  most  CSP 
sites.  CIM  rates  are  not  calculated  during  exercise  periods,  60  none 
are  avai lable. 

The  hardware  and  software  reliability  has  been  excellent  at  TCATA. 
During  the  two  and  one-half  years  that  CSP  he6  been  used  at  TCATA, 
there  has  never  been  a  time  that  TCATA  has  not  been  able  to  support  its 
users  due  to  software  or  hardware  downtimes.  The  only  system  outages 
have  been  cauBed  by  communications  line  outages. 

Given  the  high  message  volume  and  the  smalL  amount  of  disk  storage 
allocated  for  the  message  file,  the  current  configuration  allows  for 
approximately  50  days  online  storage. 

Approximately  99%  or  virtually  all  of  the  messages  received  are 
automatically  or  derivatively  routed  by  the  CSP.  This  requires  very 
little  operator  intervention. 

Future  Operations 

An  analysis  is  underway  to  replace  the  PDP-11/70  in  the  RCP  with  a 
daisy  chain  of  PDP-11/44s  and  11/24s.  As  the  RCP  is  '‘aployed,  more 
information  will  be  gathered  on  the  evolution  of  the  CSP  in  the 
tactical  environment. 

Sits  Personnel 

At  the  present  time  the  on-site  representative  at  TCATA  is  Ms. 
Elizabeth  Crenshaw,  Informatics. 

The  on-site  personnel  have  made  several  significant 
accomplishments.  From  the  time  CSP  was  first  Installed  on  the  TCATA 
PDP-11/45  system  in  November,  1979,  and  deployed  for  its  first  major 
successful  exercise  to  Europe,  January  1990,  Informatics  trained 
TCATA's  operators  and  assisted  TCATA  in  passing  Its  first  AUTODIN 
accreditation  test.  During  the  fall  of  1980,  Informatics  was  given  the 
task  of  writing  a  gateway  to  interface  with  the  TCATA  TOMCAT,  a 
replacement  for  SSB.  In  the  fall  of  1981,  Informatics  was  again  tasked 
to  write  a  site  unique  gateway,  SCMCON.  This  gateway  allowed  CSP-to- 
CSP  communications  over  a  Satellite  link.  Informatics  also  assisted  in 
integrating  the  CSP  software  onto  the  same  computer  system  as  the 
TOMCAT  resides.  In  November  of  1981,  the  present  system  successfully 
passed  a  Category  III  AUTODIN  accreditation  test. 

During  day-to-day  operations  the  Informatics  personnel  Interface 
with  the  user  organization  through  the  Systems  and  Computer  Operations 
branch  of  the  Battlefield  Automation  Test  Directorate,  TCATA.  They 
work  very  closely  with  several  branches  of  the  Special  Projects  and 
Simulation  Division  as  well  as  contractors  from  Eaton  Corporation  and 
BDM. 
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USAFE,  Ramsteln  AB ,  Germany 


Sits  Location 

CSP  was  1n8taLLad  at  HQ  United  States  Air  Force  Europe  (USAFE), 
Ramstein  AB,  Gernany  In  August,  1981.  It  Is  located  In  the  USAFE 
Combat  Operations  and  Intelligence  Center  (COIC)  and  supports  the 
Intelligence  analysts  by  providing  a  communications  path  to  AUTODIN  for 
transmission  and  reception  of  AUTODIN  messages. 

The  primary  function  of  CSP  Is  to  be  the  front-end  processor  for 
the  MAXI  system  at  USAFE  and  to  support  various  Intelligence 
communications  circuits.  A  secondary  role  Is  the  automation  of  the 
AFSSO  TCC  at  USAFE. 

Equipment  Configuration 

The  USAFE  CSP  Is  configured  on  the  following  hardware: 

o  CPU  -  One  (1)  PDP-11/70  with  256K  memory 

o  System  Console  -  One  (1)  LA36  DECwriter 

o  Disk  Drives  -  Four  (4)  BR1538C 
Two  (2)  RK05 

o  Tape  Drives  -  Three  (3)  TE16 
o  Multiplexer  -  One  (1)  BR1569 
o  Line  printers  -  One  (1)  LP05 
o  AUTODIN  Interface  Device  -  Two  (2)  TLC100 
o  Message  Distribution  Console  -  Three  (3)  OJ-389 
o  Other  Equipment  -  One  (1)  VT100  terminal 

There  Is  currently  no  backup  CPU  dedicated  for  CSP  use  at  USAFE. 
Software  Configuration 

Figure  A-07  contains  a  site  report  extracted  from  Informatics 
Configuration  Management  System.  This  report  reflects  the  current 
software  release  level  for  this  site,  the  date  of  software  Installation 
and  implementation  and  a  status  of  pending  releases.  Also  included  are 
any  site-unique  modules  developed  for  this  particular  site. 
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SITE:  USAFE  COIC  (CO) 

RELEASE:  2.2C2 

STATUS:  OPERATIONAL  26-JUL-82 

DATE  OF  INSTALLATION:  20-JUN-82 

REMARKS:  NONE 


*****«*«************************************************************************ 


UNIQUE  MODULES: 

MODULES:  TLCCON.MAC 
IDENT:  V2.2C01 

DESCRIPTION : 

ASC  BALANCING,  'EM'  STRIPPING 


Figure  A-07  USAFE  COIC  Configuration  Status 
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Communications  Configuration 


The  CSP  at  USAFE  Is  dual-homed  to  AUTODIN  via  PI  rmesens  and 
Croughton  ASCs.  There  are  two  backside  processors  configured  at  USAFE. 
There  Is  a  direct  link  to  the  MAXI  system  for  analyst  support  ss  well 
as  a  link  to  the  COIC  host  processor.  There  are  currently  no  remote 
communications  Une6  configured  at  thl6  site. 

A  connectivity  diagram  for  USAFE  Is  presented  In  Figure  A-08. 

Current  Operations  Statistics 

USAFE'6  average  traffic  volume  and  CIM  rate  are  as  follows: 
o  Messages  transmitted  -  400  per  month 

o  Messages  received  -  33,000  per  month 

o  CIM  rate  -  not  reported 

With  USAFE's  current  traffic  volume  and  message  file  size,  the 
average  on-line  message  storage  capacity  is  approximately  30  days. 
Virtually  all  of  the  incoming  traffic  is  routed  automatically  via 
derivative  routing  indicator  to  the  MAXI  system. 

The  average  reliability  of  the  CSP  software  at  USAFE  is  99.7*. 
This  figure  only  includes  outages  attributed  to  software. 

Future  Operation 

The  CSP  at  USAFE  may,  in  the  future,  front-end  the  WWMCCS  system 
and  BETA/L0CE.  This  is  dependent  upon  government  decisions  to  examine 
these  interfaces  and  requirements  in  depth.  A  MAXI  system  will  be 
connected  from  the  0SC  as  a  GENSER-only  backside  tributary.  The 
additional  traffic  load  expected  is  approximately  3000  messaages  per 
day. 


An  additional  PDP-11/70  has  been  ordered  to  serve  as  a  backup 
processor  for  CSP.  This  is  expected  in  the  fall  of  1982. 

Site  Personnel 

The  CSP  on-si te  representative  at  USAFE  is  Mr.  Raymond  Murphy, 
PRC.  Hie  dally  operations  require  direct  interface  with  the  HQ  USAFE 
Intel ligance  and  communications  staffs. 
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Figure  A-08  USAFE  Connectivity  Diagram 


LANTCOM,  Norfolk,  Virginia 


Site  Location 

CSP  was  Installed  at  CINCLANTFLT,  Norfolk,  Virginia  in  October, 
1981  and  is  being  operated  by  U.S.  Navy  data  processing  personnel. 

CSP's  primary  mission  is  to  provide  continuous  message  handling 
support  for  CINCLANTFLT' 8  Consolidated  Intelligence  Communication 
Center  (CICC).  In  addition  to  processing  messages  destined  for 
CINCLANFLT,  the  CICC  guards  for  all  major  and  most  subordinate  commands 
within  the  immediate  area.  Numerous  ships  and  embarked  staffs  require 
message  support  depending  upon  ship  movements. 

Equipment  Configuration 

The  CSP  at  LANTCOM  is  currently  implemented  on  the  following 
hardware  for  the  primary  system: 

o  CPU  -  One  (11  PDP-11/7Q  with  32QK.  memory 

o  System  Console  —  One  (1)  LA.^  OECwriter 

o  Disk  drives  -  Two  (2)  BR153BC  (shared) 

Three  (3)  BR1538D  (shared) 

o  Tape  drives  -  Two  (2)  TE16 

o  Multiplexer  -  One  (1)  8R1569  (shared) 

One  (1)  SMC200 

One  (1)  T-16 

o  Line  printers  -  Two  (2)  MOD-40  printers  (shared) 

One  (1)  LP11RA  (shared) 

o  AUTOOIN  Interface  Device  -  Two  (2)  Inteq  1A-5100  (shared) 

o  Message  Distribution  Console  -  Three  (3)  OJ-389  (shared) 

o  Other  Equipment  -  One  (1)  VT100  terminal 

One  (1)  CompuScan  COMET  OCR  (shared) 

One  (1)  AN/FGT-7  paper  tape  reader 
(shared) 

Two  (2)  AN/FGR-10  paper  tape  punch 
(shared) 

Two  (2)  MOD-40  remote  printers  (shared) 

The  backup  system  Is  configured  almost  identically  to  the  primary. 
Those  items  listed  as  "shared"  above  are  switcheble  between  the  two 
processors.  Otherwise,  the  backup  system  has  one  PDP-11/70  with  384K 
memory,  one  LA36,  and  two  TE16  tape  drives.  This  processor  also  has 
two  RK05  disk  drives. 
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Software  Configuration 


Figure  A-09  contains  a  site  report  extracted  from  Informatics 
Configuration  Management  System.  This  report  reflects  the  current 
software  release  level  for  this  site,  the  date  of  software  installation 
and  Implementation  and  a  status  of  pending  releases.  Also  included  are 
any  site-unique  modules  developed  for  this  perticular  site. 

Communications  Configuration 

The  LANTCOM  CSP  is  dual-homed  with  links  to  Andrews  end  Ft.  Detrick 
ASCs.  There  are  two  ZICON  circuits,  one  transmit/receive  and  one 
receive  only.  Other  remote  communications  lines  consist  of  two  MOD-40 
printers  located  at  LEC  and  FOSIC. 

The  backside  computer  interface  at  LANTCOM  is  configured  as  an  MSS 
line  which  terminates  in  the  CAMHS  PDP-11/70  processor.  This  Link  is 
transmit  only. 

A  connectivity  diagram  for  LANTCOM  is  presented  in  Figure  A-10. 
Current  Operations  Statistics 

LANTCOM's  average  traffic  volume  and  CIM  rate  are  as  folLows: 
o  Messages  transmitted  -  2,475  per  month 
o  Messages  received  -  45,000  per  month 
o  Line  blocks  transmitted  -  52,700  per  month 

o  Line  blocks  received  -  1,100,000  per  month 

o  CIM  rate  -  .81* 

Even  with  the  high  volume  processed  by  LANTCOM,  the  CSP  is  able  to 
maintain  approximately  35  days  of  online  storage.  A  low  CIM  rate  has 
been  maintained  as  a  result  of  the  extensive  format  and  security  checks 
performed  by  CSP. 

All  incoming  messages  are  received  end  routed  by  MDC  operators; 
none  are  automatically  or  derivatively  routed. 

The  station  reliability  for  LANTCOM  including  both  hardware  and 
software  outages  is  approximately  99.5*. 


SITE:  CINCLANT  J-2  (LA) 

RELEASE:  2.2C2 

STATUS:  OPERATIONAL  24-APR-82 

DATE  OF  INSTALLATION:  25-APR-B2 

REMARKS:  NONE 


******************************************************************************** 


UNIQUE  MODULES: 

MODULES:  FRMTCK.MAC 
I DENT:  V2.2LA2 

DESCRIPTION : 

BYPASS  LINE  VALIDATION  FOR  ALL  FORMAT  LINES  EXCEPT  2  AND  16  FOR  CRITIC 
MESSAGES.  APPEND  CORRECT  EDM  SEQUENCE  IF  MISSING  OR  INCORRECT. 

CRITIC  MESSAGE  INCORRECTLY  FORMATTED  ARE  BEING  DELAYED  DUE  TO  REJECTION 
TO  THE  SVC.  THE  TIMELINESS  REQUIRED  FOR  CRITIC  MESSAGES  DEMANDS 
IMMEDIATE  PROCESSING. 

MODULES:  INGATE. MAC 
IDENT;  V2.2LA1 
DESCRIPTION : 

INTERFACE  UNIQUE  ROMS 

MODULES:  ITQCON.MAC 
IDENT:  V2.2LA1 

DESCRIPTION : 

INTEQ  AID-21 
RENAMED  FROM  TLCCON 


Figure  A-09  CINCLANT  J-2  Configuration  Status 


Future  Operations 

There  are  plans  to  Implement  a  transmit/ receive  interface  to  the 
OSIS  baseline  SUBLANT,  and  upgrade  the  CAMHS  Interface  to  full  duplex. 
The  software  will  have  to  be  reconfigured  to  add  the  additional  lines 
end  queues  as  necessary  to  support  these  changes.  When  this  occurs, 
there  will  be  somewhat  of  an  increase  in  the  traffic  Load  on  the  CSP. 

With  the  implementation  of  CSP  Release  2.3,  LANTCOM  plans  to 
convert  to  a  dumb  optical  character  reader  end  use  the  PLA  capabilities 
of  tha  CSP. 

Sice  Personnel 

The  CUBIC/CSP  on-site  representative  at  LANTCOM  is  Mr.  John  Strama, 
Informatics.  Mr.  Strama  works  closely  with  both  the  data  processing 
and  communications  staffs  of  CINCLANTFLT  in  his  daily  operations.  His 
primary  point  of  contact  is  CINCLANTFLT- J2 91 . 


FTD,  Wright-Pattarson  AFB,  Ohio 


Site  Location 

CSP  was  Installed  at  the  Foreign  Technology  Division  (FTD), 
Wri ght-Patterson  AFB,  Ohio  in  June,  1982. 

FTD  produces  scientific  and  technical  intelligence  (S&TI)  to 
provide  current  foreign  aerospace  technical  threat  assessments  for  use 
in  AFSC  systems  planning  an  acquistion.  In  addition,  FTD  is 
responsible  for  providing  foreign  aerospace  technological  data  and  data 
analysis  support  to  HQ  USAF,  major  commands,  NASA,  agencies  of  the 
national  intelligence  community  and  R&D  support. 

CSP  supports  this  mission  by  providing  real  time  transmission  and 
reception  of  AUTODIN  message  communications. 

Equipment  Configuration 

The  CSP  is  currently  implemented  on  thB  following  equipment: 

o  CPU  -  One  (1)  PDP-11/70  with  192K  memory 

o  System  Console  -  One  (1J  LA36  DECwriter 

o  Disk  Drives  -  Two  (2)  BR1538C 

o  Tape  Drives  -  Three  (3)  TU16  drives 

o  Multiplexer  -  One  (1)  32  channel  BR1569 

o  Line  Printers  -  Two  (2)  Dataproducts  2267,  BOO  1pm 

One  (1)  Dataproducts  2470,  1200  1pm 

o  AUTODIN  Interface  Device  -  One  (1)  TLC100 

o  Message  Distribution  Console  -  Two  (2)  OJ-389 

o  Other  Equipment  -  Two  (2)  ASR-28  paper  tape  readers 

One  (1)  CR-11  card  Reader 
Two  (2)  VT-52  terminals 

All  of  the  above  equipment  is  configured  as  one  operational  CSP. 
There  la  no  second  processor  or  set  of  peripherals  to  be  used  as  a 
backup.  The  current  backup  will  be  provided  manually  through  a  DSTE. 
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Software  Configuration 


Figure  A-11  contains  a  site  report  extracted  from  Informatics 
Configuration  Management  System.  This  report  reflects  the  current 
software  release  level  for  this  site,  the  date  of  software  installation 
and  implementation  and  a  status  of  pending  releases.  Also  included  are 
any  site-unique  modules  developed  for  this  particular  site. 

Communications  Configuration 

The  CSP  is  currently  connected  to  the  ASC  at  Gentile  for  online 
operations  with  the  Andrews  ASC  permanently  altrouted  to  the  same  line. 
In  the  event  of  a  circuit  outage,  the  Andrews  line  will  be  activated  on 
the  DSTE. 

There  are  no  other  local  tributaries  configured  as  direct  electrical 
links  at  this  time.  There  are,  however,  five  organizations  with 
computer  systems  which  are  serviced  with  a  magnetic  tape  interface.  A 
connectivity  diagram  is  illustrated  in  Figure  A-12. 

Current  Operations  Statistics 

FTD's  average  traffic  volume  and  CIM  rate  are  as  follows: 
o  Messages  transmitted  -  1,825  per  month 
o  Messages  received  -  25,000  per  month 
o  Line  blocks  transmitted  -  40,000  per  month 
o  Line  blocks  received  -  900,000  per  month 
o  CIM  rate  -  1 .45* 

Given  this  traffic  volume  and  the  capacity  of  the  message  file,  it 
1 8  anticipated  that  the  online  message  storage  capacity  will  be 
approximately  35  days. 

Since  there  are  no  automated  backside  processors,  no  messages  are 
derivatively  routed  and  all  messages  are  manually  received  by  the  MDC 
operators.  The  MX  clerk  determines  routing  for  all  Incoming  messages 
and  places  each  message  on  selected  output  queues  for  either  hardcopy 
or  mag-tape  distribution.  Meg-tape  messages  ere  altrouted  to  the 
Intercept  tape  during  normal  operation  of  CSP.  Once  daily,  these 
messages  are  placed  on  their  respective  mag-tapes  end  hand-carried  to 
the  responsible  organizations. 


SITE:  FTD  (FT) 


RELEASE:  2.2C2 


STATUS:  OPERATIONAL 


DATE  OF  INSTALLATION: 


REMARKS:  NONE 


27-SEP-82 


25-JUN-82 


******************************************************************************** 

UNIQUE  MODULES: 

MODULES:  MD2C0N . MAC 
IDENT:  V2.2FT1 

DESCRIPTION: 

ENABLES  PAPER  TAPE  READER 

MODULES:  MD2CTL.MAC 
IDENT:  V2.2FT1 

DESCRIPTION: 

ENABLES  THE  PAPER  TAPE  READER 


MODULES:  MD2DAT.MAC 
IDENT:  V2.2FT1 

DESCRIPTION : 

ENABLES  PAPER  TAPE  READER 

MODULES:  MD20T  .MAC 
IDENT:  V2.2FT1 

DESCRIPTION: 

ENABLES  PAPER  TAPE  READER 

MODULES:  MD20UT.MAC 
IDENT:  V2.2FT1 

DESCRIPTION : 

ENABLES  PAPER  TAPE  READER 

MODULES:  RELEAS.MAC 
IDENT:  V2.2FT1 

DESCRIPTION : 

MODIFIED  TO  SUPPORT  THIRD  PRINTER 


Figure  A-ll  FTD  Configuration  Status 
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Figure  A-12  FTD  Connectivity  Diagram 


Future  Operations 


There  are  plans  to  procure  one  more  OJ-389,  an  additional  TLC100 
and  implement  an  optical  character  reader  interface  as  the  equipment 
becomes  available.  Also,  at  some  point  in  the  future  the  BR1538C  disk 
drives  will  be  upgraded  to  BR1538D  drives,  increasing  the  capacity  to 
300  MB  each. 

The  problem  with  no  CSP  backup  will  be  alleviated  by  the 
procurement  of  an  additional  PDP-11/70  system  as  soon  as  it  is 
avai lable. 

With  the  implementation  of  CSP  Release  3.0,  a  new  capability  will 
be  provided  to  allow  remote  OJ-389  dissemination  terminals.  At  this 
time,  FTD's  mode  of  operation  will  change  to  bILow  the  MDC  clerk  to 
disseminate  only  administrative  messages  while  all  substantive 
intelligence  messages  will  be  routed  by  a  remote  intelligence  staff. 
This  should  not  impact  total  traffic  volume  but  would  6hift  the  burden 
from  the  TCC  operator. 

Site  Personnel 

There  are  currently  no  contractor  personnel  on-site  at  FTD.  All 
on-site  maintenance  is  provided  by  FTO  personnel  for  identification  of 
problems  and  routine  table  maintenance.  Problems  wiLl  be  resolved  by 
the  centralized  development  staff  in  Bellevue  and  solutions  will  be 
communicated  to  FTD  personnel  for  implementation. 
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ADCOM,  Colorado  Springs,  Colorado 


Site  Locations 

CSP  was  Installed  at  HQ  Air  Defense  Command,  Cheyenne  Mountain 
Complex,  Colorado  Springs,  Colorado  In  August,  1982,  and  was  placed 
online  In  October,  1982. 

The  NORAD/ADCOM  community  provides  surveillance,  detection  end 
early  warning  for  the  North  American  continent  end  Its  perimeters.  The 
CSP  will  support  this  mission  by  providing  real-time  transmission  end 
reception  of  AUTODIN  message  communications. 

Equipment  Configuration 

The  CSP  is  currently  implemented  on  the  following  hardware  for  the 
primary  system: 

o  CPU  -  One  (1)  PDP-11/70  with  256K  memory 

o  System  Console  -  One  (1)  LAI 20  DECwriter 

o  Disk  Drives  -  Three  (3)  BR1538D  (shared) 

One  (1)  RK01 

o  Tape  Drives  -  Two  (2)  TE16  (shared) 

One  (1)  TE1B 

o  Multiplexer  -  One  (1)  BR1731 

o  Line  printers  -  One  (1)  LP11VA  (shared) 

One  (1)  LP11VA 

o  AUTODIN  Interface  Device  -  Two  (2)  TLC100  (shared) 

o  Message  Distribution  Console  -  Three  (3)  OJ-389  (shared) 

o  Other  Equipment  -  One  (1)  PC11  Paper  Tape  Reader/Punch 

(shared) 

One  (1)  CR11  Card  Reader  (shared) 

One  (1)  VT100  terminal 

The  backup  system  Is  configured  exactly  the  same  as  the  primary 
system,  so  full  redundancy  Is  provided.  Those  Items  listed  as  shared 
are  swltchable  between  the  two  processors  through  e  DT07  unibus  switch. 


Software  Configuration 


Figure  A-13  contains  a  site  report  extracted  from  Informatics 
Configuration  Management  System.  ThiB  report  reflects  the  current 
software  release  level  for  this  site,  the  date  of  software  installation 
and  implementation  and  a  status  of  pending  releases.  Also  included  are 
any  site-unique  modules  developed  for  this  particular  site. 

Communications  Configuration 

ACCOM's  CSP  has  links  to  two  ASCs,  McClellan  and  Tinker.  In 
addition,  there  is  a  link  to  the  NCMC  command  post  which  is  configured 
as  a  Mode  II  circuit. 

A  connectivity  diagram  is  presented  in  Figure  A-14. 

Current  Operations  Statistics 

AOCOM's  average  traffic  volume  end  CIM  rate  are  as  follows: 
o  Messages  transmitted  -  1,800  per  month 
o  Massages  received  -  35,000  per  month 
o  CIM  rate  -  1 .30%  average 

Given  thi6  traffic  volume  and  the  capacity  of  the  message  file,  it 
Is  anticipated  that  the  on-line  message  storage  capacity  will  be 
approximately  40  days. 

Future  Operations 

There  are  no  known  changes  to  the  planned  hardware  configuration  at 
ADC0M.  However,  as  soon  as  CSP  Release  3.0  Is  implemented,  ADCOM  plans 
to  use  the  remote  OJ-389  dissemination  capability.  The  actual  mode  of 
operation,  however,  is  unknown  at  this  time. 

Sits  Personnel 

The  CUBIC/CSP  on-site  representative  at  A0C0M  Is  Ms.  Bonnie  Rosado, 
Informatics.  She  Interfaces  on  e  daily  basis  with  the  ADCOM 
communications  staff. 
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SITE:  ACCOM  (AO) 


RELEASE:  2.2C2 

STATUS:  OPERATIONAL  25-0CT-82 
DATE  OF  INSTALLATION:  20-AUG-B2 
REMARKS:  NONE 


UNIQUE  MODULES: 
NONE 


Figure  A-13  ADCGM  Configuration  Status 
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Figure  A -14  ADCOM  Connectivity  Diagram 


HQ  CINCPAC,  Camp  H.M.  Smith,  Hawaii 


Site  Location 

CSP  was  Installed  at  HQ  Commander-in-chief  Pacific  in  July  1979. 
This  installation  was  reaccredited  by  DIA  and  OCA  in  July  1982.  The 
occassion  for  this  reaccreditation  was  the  implementation  of  the  Fully 
Automated  Routing  of  Messages  (FARM)  software  package  developed  by  the 
CSP  programmer  assigned  to  CINCPAC.  This  software  package  will  be 
included  in  the  CUBIC/CSP  baseline,  and  wiLl  be  distributed  to  CSP  users 
as  their  systems  are  updated  with  the  current  baseline. 

The  Pacific  Command  IPACOM)  area  consists  of  approximately  96 
million  square  miles  and  contains  two-thirds  of  the  world's  population. 
The  type,  level  and  degree  of  threat  to  U.S.  national  interest  ranges 
from  the  strategic  nuclear  forces  of  the  Soviet  Union  to  the 
guerri lla/insurgency  threat  in  the  Southern  and  Southeast  Asian  areas. 
The  mission  of  the  Commander-in-chief,  Pacific  (CINCPAC),  is  "To 
maintain  the  security  of  PACOM  and  defend  the  United  States  against 
attack  through  the  Pacific  Ocean;  to  support  and  advance  the  national 
policies  and  interests  of  the  United  States  and  discharge  U.S.  military 
responsibilities  in  the  Pacific,  Far  East,  Southeast  and  South  Asia;  to 
prepare  plans,  conduct  operations  and  coordinate  activities  of  the 
forces  of  the  PACOM  in  consonance  with  directives  of  higher  authority." 

CSP  provides  OSSCS  Communications  Support  for  transmission  end 
reception  of  real-time  AUTOOIN  messages  in  support  of  CINCPAC' s  mission. 
In  addition,  the  CSP  functions  as  a  front-end  processor  for  the  PACOM 
Data  Systems  Center  (PDSC)  system,  which  directly  support  CINCPAC's 
intelligence  analysts.  The  PDSC  computer  system  is  a  derivative  of  the 
MAXI  system. 

Equipment  Configuration 

The  CSP  at  CINCPAC  Is  currently  implemented  on  the  following 
hardware  for  the  primary  system: 

o  CUP  -  One  (1)  PDP-11/70  with  256K  memory 

o  System  console  -  One  (1)  LA36  DECwriter 

o  Disk  drives  -  Three  (3)  BR1538D  (shared) 

o  Tape  drives  -  Two  (2)  TE10 

Three  (3)  TU45  (shared) 

o  Multiplexer  -  One  (1)  36  channel  BR1569 

o  Line  printers  -  One  (1)  LP11  RA  (shared) 

Two  (2)  TT  Model  4010  (shared) 

One  (1)  TT  Model  4030  (shared) 
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AUTODIN  interface  device  -  Two  (2)  INTEQ  (shared) 

o  Message  distribution  console  -  Three  (3)  OJ-389  (shared) 

o  Other  equipment  -  One  (1)  VT52  Terminal  (shared) 

Four  (4)  Paper  Tape  Reader/Punch 
(shared) 

One  (1)  Card  Reader  (shared) 

One  (1)  Unibus-Unibus  link 
'One  (1)  OCR  (shared) 

The  backup  system  is  configured  identically  to  the  primary.  Those 
items  listed  as  "shared"  above  are  switchable  between  the  two 
processors.  Additionally,  individual  circuits  terminating  in  the  BR1569 
multiplexer  are  switchable  between  both  processors. 

Software  Configuration 

Figure  A-15  contains  a  6i te  report  extracted  from  Informatics 
Configuration  Management  System.  This  report  refLects  the  current 
software  release  level  for  this  site,  the  date  of  software  installation 
and  implementation,  and  a  status  of  pending  releases.  Also  included 
are  any  site  unique  modules  developed  for  thiB  particular  site. 

Communications  Configuration 

The  CSP  Is  dual-homed  to  McCellan  and  Wahiawa  ASCs  for  online 
tributary  operations,  DSSCS  only.  The  only  backside  tributary  at 
CINCPAC  is  the  PDSC  system,  a  derivative  of  the  MAXI  system. 

A  connectivity  diagram  for  CINCPAC  is  presented  in  Figure  A-16. 
Current  Operations  Statistics 

o  Messages  transmitted  -  1,500  par  month 
o  Messages  received  -  53,600  per  month 
o  CIM  Rate  -  2X 

The  CSP  1 8  able  to  maintain  approximately  60  days  of  online 
storage.  CINCPAC  has  been  able  to  maintain  a  low  CIM  rate  due  to  the 
extensive  format  and  security  checks  performed  by  the  CSP. 

Approximately  75X  of  the  incoming  messages  are  derivatively  routed 
to  PDSC.  The  remainder  are  routed  by  the  Message  Distribution  Clerk. 

The  reliability  for  CINCPAC  Including  both  hardware  and  software 
outages  Is  approximately  99X. 
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SITE:  CINCPAC  (PD) 

RELEASE:  2.2C2 

STATUS:  OPERATIONAL  30-JUL-82 

DATE  OF  INSTALLATION:  23-JUL-82 

REMARKS:  NONE 


******************************************************************************** 

UNIQUE  MODULES: 

MODULES:  ARMMCR . MAC 
I DENT:  V2.2PD1 

DESCRIPTION: 

FARM  UPDATE  PROGRAM 

MODULES:  ARUPDT.MAC 
IDENT:  V2.2PD1 

DESCRIPTION: 

NONE 

MODULES:  AUTCON.MAC 
IDENT:  V2.2PD1 

DESCRIPTION : 

INTEQ  AID 

MODULES:  AUTORM.MAC 
IDENT:  V2.2PD1 

DESCRIPTION: 

PDSC  FARM  MODULE. 

MODULES:  CANCON.MAC 
IDENT:  V2.2PD1 

DESCRIPTION : 

MODIFIED  FOR  IMPLEMENTATION  OF  A  VFK  TO  INPUT  A  CANNED  CRITIC  HEADER. 

MODULES:  COMMLC.MAC 
IDENT:  V2.2PD1 

DESCRIPTION: 

PROCESS  ON/OFF  REQUEST  FOR  PDSC  LINES 

MODULES:  DCTRDR.MAC 
IDENT:  V2.2PD1 

DESCRIPTION : 

NONE 

MODULES:  DCTREF.MAC 
IDENT:  V2.2PD1 

DESCRIPTION : 

NONE 

Figure  A-15  CINCPAC  Configuration  Status  (Page  1  of  4) 
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MODULES:  DECODE. MAC 
I DENT :  V2.2PD1 

DESCRIPTION: 

MODIFIED  FOR  IMPLEMENTATION  OF  ADDITIONAL  FIXED  DISSEMINTATION  VFK'S. 
ALSO  MODIFIED  FOR  IMPLEMENTATION  OF  A  VFK  TO  INPUT  A  CANNED  CRITIC 
HEADER. 

MODULES:  DINCON.MAC 
I DENT:  V2.2P01 

DESCRIPTION: 

AUTODIN  TEST  MESSAGE  GENERATION  [VERSION  OF  FCSCON). 

MODULES:  DISSEM.MAC 
IDENT:  V2.2PD1 

DESCRIPTION: 

MODIFIED  FOR  IMPLEMENTATION  OF  ADDITIONAL  FIXED  DISSEMINATION  VFK'S. 
MADE  CORRECTION  TO  BUG  IN  REF  RECORD  DISK  ACCESS  GENERATION. 

MODULES:  DMCDRV.MAC 
IDENT:  V2.2PD1 

DESCRIPTION: 

PDSC  DMC  MODULE(S)  STATUS  UNKNOWN. 

MODULES:  DMCGTY. MAC 
IDENT:  V2.2PD1 

DESCRIPTION: 

PDSC  CMD  MODULEIS]  STATUS  UNKNOWN. 

MODULES:  DSPACS.MAC 
IDENT:  V2.2PD1 

DESCRIPTION : 

DISPLAY  MSS  LINE  STATUS 

MODULES:  FARM  .MAC 
IDENT;  V2.2PD1 
DESCRIPTION: 

MCR  CONTROL. 

MODULES:  FCSCON. MAC 
IDENT:  V2.2PD1 

DESCRIPTION: 

NONE 

MODULES:  KPT A  .MAC 
IDENT:  V2.2PD1 

DESCRIPTION: 

MOD  40  PSEUDO  HANDLER. 

MODULES:  MSSGWY.MAC 
IDENT:  V2.2PD1 

DESCRIPTION: 

GATEWAY  FOR  PDSC  TO  CSP. 

MODULES:  OCRCON.MAC 
IDENT:  V2.2PD1 

DESCRIPTION: 

NONE 


Figure  A-15  CINCPAC  Configuration  Status  (Page  2  of  4) 
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MODULES:  OEEGWY.MAC 
I DENT:  V2.2PD1 

DESCRIPTION: 

NONE 

MODULES:  OSUPDT.MAC 
IDENT:  V2.2PD1 

DESCRIPTION: 

MODIFIED  FOR  IMPLEMENTATION  OF  ADDITIONAL  FIXED  DISSEMINATION  VFK'S.  ALSO 
MODIFIED  FOR  IMPLEMENTATION  OF  A  VFK  TO  INPUT  A  CANNED  CRITIC  HEADER. 

MODULES:  PAGCON.MAC 
IDENT:  V2.2PD1 

DESCRIPTION: 

MODIFIED  TO  DELETE  ALL  OF  THE  OLD  COPY  OF  A  MESSAGE  WHEN  THE  MESSAGE  IS 
EDITED.  CARRY  OVER  OF  INPUT  CDSN  FROM  THE  OLD  TO  THE  NEW  COPY  OF  A  MESSAGE 
WHEN  IT  IS  EDITED.  NOW  PROVIDES  CAPABILITY  TO  PAGE  FORWARD  THROUGH  A 
MESSAGE  RETURNING  TO  THE  FIRST  PAGE  AFTER  THE  LAST  PAGE  HAS  BEEN  DISPLAYED. 
MADE  CORRECTION  TO  PREVENT  OCCASIONAL  CORRUPTION  OF  A  MESSAGE  WHEN  THE  NEW 
LINE  KEY  IS  USED.  MADE  CORRECTION  TO  ELIMINATE  THE  PERIODIC  LOCK-OUT  OF 
THE  TERMINAL  PAGING  KEYS.  MADE  CORRECTION  TO  THE  HANDLING  OF  THE  NEXT 
PREVENT  PAGE  KEYS  WHILE  THE  TEMINAL  IS  BUSY. 

MODULES:  RDPGWY.MAC 
IDENT:  V2.2PD1 

DESCRIPTION: 

NONE 

MODULES:  RESET  .MAC 
IDENT:  V2.2PD1 

DESCRIPTION: 

MODIFIED  FOR  IMPLEMENTATION  OF  ADDITIONAL  FIXED  DISSEMINATION  VFK'S. 

MADE  CORRECTION  TO  BUG  IN  REF  RECORD  DISK  ACCESS  GENERATION. 

MODULES:  STSTAT.MAC 
IDENT:  V2.2PD1 

DESCRIPTION: 

NONE 

MODULES:  SVCCON.MAC 
IDENT;  V2.2PD1 
DESCRIPTION: 

TEST  MESSAGE  GENERATION  (VERSION  OF  FCSCON). 

MODULES:  TIMSTP.MAC 
IDENT:  V2.2PD1 

DESCRIPTION: 

SYSTEM  CONSOLE  TIME  STAMP  ROUTINE. 

MODULES:  TRMNEW.MAC 
IDENT:  V2.2PD1 

DESCRIPTION: 

MADE  CORRECTION  TO  ELIMINATE  THE  PERIODIC  LOCK-OUT  OF  TERMINAL  PAGING 
KEYS.  MADE  CORRECTION  TO  THE  HANDLING  OF  THE  NEXT/PREVIOUS  PAGE  KEYS 
WHILE  THE  TERMINAL  IS  BUSY. 

Figure  A-15  CINCPAC  Configuration  Status  (Page  3  of  43 
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MODULES:  TRMOLO.MAC 
IDENT:  V2.2PD1 

DESCRIPTION : 

MADE  CORRECTION  TO  ELIMINATE  THE  PERIODIC  LOCK-OUT  OF  TERMINAL  PAGING 
KEYS.  MADE  CORRECTION  TO  THE  HANDLING  OF  THE  NEXT/PREVIOUS  PAGE  KEYS 
WHILE  THE  TERMINAL  IS  SUSY 

MODULES:  TSTCON.MAC 
IDENT:  V2.2PD1 

DESCRIPTION : 

TEST  MESSAGE  GENERATION  (VERSION  OF  FCSCON). 

MODULES:  USEREQ.MAC 
IDENT:  V2.2PD1 

DESCRIPTION : 

MADE  CORRECTION  TO  EXTRANEOUS  DELIVERY  OF  MESSAGE  WHEN  RELEASE  AUTHORITY 
IS  GRANTED. 


\ 
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Future  Operations 

CINCPAC  was  the  first  CSP  site  to  Implement  the  Fully  Automated 
Flouting  of  Messages  (FARM]  software.  This  software  was  developed  by 
other  contractor  personnel  at  CINCPAC.  This  software  Is  expected  to 
reduce  the  amount  of  messages  which  must  be  manually  disseminated  by 
approximately  80%. 

Site  Personnel 

There  are  no  CUBIC/CSP  on-site  representatives  at  CINCPAC. 
Informatics  facility  at  Bellevue  coordinates  with  the  communications 
personnel  of  CINCPAC  to  resoLve  system  problems. 
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